☰

非常奇怪的 Debian 问题：无法从任何公共 IP 连接到 Debian 上运行的任何服务，使用私有 IP 可以正常工作

tag-icon • tag-icon networking debian
非常奇怪的 Debian 问题：无法从任何公共 IP 连接到 Debian 上运行的任何服务，使用私有 IP 可以正常工作

首先，这不是端口转发问题。通过运行 tcpdump，我可以看到请求到达 debian 服务器，然后它们停止了。

我的 Debian 服务器运行的是 apache 和 PleX。如果我使用 192.168.1.210 连接到 Debian 服务器，它运行完美。我可以看到网页，也可以从 PleX 流式传输。

如果我离开我的网络，比如说，我去朋友家，我也无法访问。使用 tcpdump，我可以看到数据包到达服务器，但仅此而已。canyouseeme.org 也是如此。

我做有一些路由和 iptables。我使用这台机器进行 torrenting + VPN，所以我使用路由来保持一切正常。路由应该让 PleX 远离 tun0（VPN 接口），而 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，NAT 会以某种方式修改它的源，然后返回到您的朋友那里，并由于源地址错误而被丢弃。

可能的修复方法：1：将你朋友的 IP 添加到路由表，显然扩展性不是很好，可能会导致 torrent 流量泄漏。2：如果你的 nat 盒是一个合适的 linux 系统，应该可以对其进行配置以更改传入连接的源和目标。这样你的 torrent 盒就会将 NAT 盒视为源，而不是在互联网上看到你朋友的系统。3：使用 linux 中的“高级路由”功能根据源端口进行路由。不幸的是，高级路由功能非常强大，但也很难理解。如果你想要更多关于这条路线的信息，请查看“linux 高级路由和流量控制指南”

相关内容