非常奇怪的 debian 問題:無法從任何公共 IP 連接到 Debian 上運行的任何服務,但在私人 IP 上工作正常

非常奇怪的 debian 問題:無法從任何公共 IP 連接到 Debian 上運行的任何服務,但在私人 IP 上工作正常

首先,這不是連接埠轉送問題。透過執行 tcpdump,我可以看到請求到達 debian 伺服器,然後停止。

我的 debian 伺服器運行 apache 和 PleX。如果我使用 192.168.1.210 連接到 Debian 伺服器,它可以完美運行。我可以查看網頁,並且可以從 PleX 進行串流傳輸。

如果我離開網絡,比如說,我去朋友家,我也無法訪問。使用 tcpdump,我可以看到資料包到達伺服器,但僅此而已。與 canyouseeme.org 相同。

有一些路由和 iptables 到位。我使用這台機器進行種子下載 + VPN,因此我使用路由來保持一切正常運行。路由應該會使 PleX 遠離 VPN 介面 tun0,並且 iptables 應該阻止用戶 debian-transmission 使用 tun0 以外的任何東西。

 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.172.1.5      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
10.172.1.1      10.172.1.5      255.255.255.255 UGH   0      0        0 tun0
10.172.1.5      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
50.18.0.0       192.168.1.1     255.255.0.0     UG    0      0        0 eth0
54.241.0.0      192.168.1.1     255.255.0.0     UG    0      0        0 eth0
128.0.0.0       10.172.1.5      128.0.0.0       UG    0      0        0 tun0
184.72.0.0      192.168.1.1     255.255.192.0   UG    0      0        0 eth0
184.169.128.0   192.168.1.1     255.255.128.0   UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
216.144.236.186 192.168.1.1     255.255.255.255 UGH   0      0        0 eth0

iptables:

target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.1.0/24       owner UID match debian-transmission
REJECT     all  --  anywhere             anywhere             owner UID match debian-transmission reject-with icmp-port-unreachable

答案1

透過範例來描述正在發生的情況可能是最簡單的。

假設您的 NAT 路由器 IP 位址是 1.1.1.1,您朋友的 IP 位址是 2.2.2.2 為了簡單起見,我們還假設您的朋友不在 nat 路由器後面(如果他們是,則範例會稍微複雜一些,但它我也假設連接埠轉送將外部IP 上的連接埠80 轉送到Debian 機器上的連接埠80。

您朋友的電腦發送一個 syn 封包,其來源位址為 2.2.2.2、隨機選擇的來源連接埠(假設為 12345)、目標位址為 1.1.1.1、目標連接埠為 80

封包到達您的 NAT,它會尋找轉送連接埠並將目標 IP 變更為 192.168.1.210。來源 IP 保持為 2.2.2.2,連接埠保持不變。建立映射,以便可以對傳回的資料包執行反向轉換,到目前為止一切順利。

資料包到達您的伺服器。它被傳送到 TCP 堆疊,該堆疊創建一個 ack 封包作為回應。正常情況下,當資料包回復到來源和目的地時會交換。因此,此封包的來源位址為 192.168.1.210 ,目標位址為 2.2.2.2 ,來源連接埠為 80 ,目標埠為 12345 。

回覆離開 TCP 堆疊並到達 iptables。您的規則正在執行 UID 匹配,因此所有者匹配工作正常,資料包應該通過那裡。

然後它訪問路由表。這會將其傳送到 VPN。它命中 VPN 中的 NAT,以某種方式修改其來源,返回給您的朋友,並由於來源位址錯誤而被丟棄。

可能的修復: 1:將您朋友的 IP 添加到路由表中,顯然擴展性不太好,可能會導致 torrent 流量洩漏。 2:如果您的 nat 盒子是合適的 Linux 系統,則應該可以對其進行配置以更改傳入連接的來源和目的地。因此,您的 torrent 盒子會將 NAT 盒子視為來源,而不是在網路上看到您朋友的系統。 3:利用linux中的「進階路由」功能,依照來源連接埠進行路由。不幸的是,進階路由功能非常強大,但也很難理解。如果您想了解有關此路線的更多信息,請查看“Linux 高級路由和流量控制指南”

相關內容