☰

无法从内部网络 ping 静态 IP，只能从外部

tag-icon • tag-icon networking ping localhost
无法从内部网络 ping 静态 IP，只能从外部

我正在运行 ubuntu，并且正在运行 apache，但是，我无法内部 ping 到我的静态 IP，也无法http://207.40.XXX.XX使用我的静态 IP 浏览 Web 服务器。我只能 ping/浏览localhost, 127.0.0.1, and 192.168.0.120 或者 207.40.XXX.XX仅与外界隔绝。

# cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       my-server.myhost.com my-server

# hostname
my-server

# netstat -tapn
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -                  
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:29754         0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN

知道为什么这不起作用吗？

答案1

您的 NAT 网关的行为不允许这样做。它的工作方式可能是这样的：

平

  1. 您从 192.168.0.5 向 207.40.123.45 发送 ICMP Echo 请求
  2. 这将通过您的路由器进行路由。
  3. 路由器内的 NAT 网关将请求重写为来自 207.40.123.45（静态 IP 地址）
  4. 您的路由器回复 ICMP Echo 请求
  5. 由于您的路由器不支持 ICMP 状态，它永远不会将 ECHO 回复传回给您。

HTTP

  1. 你从 192.168.0.5 向 207.40.123.45 发送 TCP/80 连接请求
  2. 这将通过您的路由器进行路由
  3. 您的 NAT 网关将数据包重写为从207.40.123.45:41345 至 207.40.123.45:80
  4. 您的 NAT 网关注意到有一个端口转发，因此将数据包转发到 192.168.0.120:80
  5. 192.168.0.120 的服务器回复来自 207.40.123.45:41345 的连接尝试
  6. 您的 NAT 网关看到回复并将回复中的收件人：地址重写为 192.168.0.5:36311，但发件人：保持不变（192.168.0.120:80）
  7. 您的位于 192.168.0.5 的计算机从 192.168.0.120 收到一个它从未请求过的数据包，并将其丢弃在地上。
  8. 您的连接不稳定，始终无法接通。’

请注意，ping 失败的原因可能与 HTTP 失败的原因相同。这称为“NAT Hairpinning”。

你所需要的是一个足够智能的 NAT 网关，它在步骤 6 中还会重写来源地址。

答案2

虽然 1138 的答案是正确的，但我只是想详细解释一下“发夹式 NAT”是什么、它是如何工作的，以及为什么在这种情况下它是必要的。如果你不关心 IP、NAT 和路由的细节，请随意忽略我（相当冗长的）答案的其余部分。

如果不考虑发夹弯，以下是本地 LAN 客户端 (192.168.0.5) 通过外部 IP 地址 (207.40.123.45) 尝试与 Web 服务器建立 HTTP 连接时发生的情况：

  1. 192.168.0.5 将其 SYN 数据包发送到 207.40.123.45，端口 80。由于 207.40.123.45 不在本地网络上，因此此数据包被发送到默认网关（即路由器）。

  2. 路由器配置为将 207.40.123.45:80 转发到 192.168.0.120:80，将数据包的目标地址重写为 192.168.0.120，然后将数据包传送到 Web 服务器。

  3. Web 服务器收到 SYN 数据包，并向发送者的地址发送一个回复 SYN-ACK 数据包，该数据包192.168.0.5由于 192.168.0.5 位于同一网络，因此 Web 服务器将数据包直接传送到 192.168.0.5。

  4. 来自的 SYN-ACK 数据包192.168.0.120到达 192.168.0.5，但那里的主机没有期待来自 192.168.0.120 的 SYN-ACK，因此被丢弃/拒绝。192.168.0.5 的主机继续等待来自 207.40.123.45 的 SYN-ACK 回复，但当然，该数据包永远不会到达。连接尝试最终会超时，可能在重试几次之后，最终，客户端和 Web 服务器无法建立连接。

这个问题可以通过步骤 2 中的路由器来解决，即应用“发夹 NAT”。简而言之，解决方案是诱使客户端和 Web 服务器通过路由器发送相互流量。这可以通过应用NAT 的第二阶段在步骤 2 中，除了通常用于端口转发的一个阶段之外。以下是该序列，这次添加了发夹式 NAT：

  1. 与之前一样，192.168.0.5 向路由器发送发往 207.40.123.45、端口 80 的 SYN 数据包。

  2. 和以前一样，路由器接收 SYN 数据包，并根据其配置的端口转发规则，将目标地址重写为 192.168.0.120。但这一次，路由器注意到它即将把数据包“发夹”回接收数据包的同一网络，因此它还会重写数据包的源地址到路由器自己的 LAN 地址（例如：192.168.0.1）。然后路由器将数据包传送到 192.168.0.120 的 Web 服务器。

  3. Web 服务器收到 SYN 数据包，并将其回复 SYN-ACK 数据包发送回发送者的地址，这次的地址是192.168.0.1. 因此，答复返回到路由器。

  4. 路由器收到来自 Web 服务器的 SYN-ACK，并识别出这是对最近 NAT 过的数据包的回复（两次）。因此，路由器会尽职尽责地反转两次 NAT，回复数据包现在具有源地址 207.40.123.45 和目标地址 192.168.0.5。因此，回复被传送到 192.168.0.5，TCP 连接握手继续，客户端和 Web 服务器能够成功通信。

因此，在路由器支持发夹式连接的情况下，192.168.0.5 处的主机会认为它正在与 207.40.123.45 处的 Web 服务器通信，而 192.168.0.120 处的 Web 服务器会认为它正在与路由器本身 (192.168.0.1) 上的客户端通信。在发夹式连接时，两台主机之间的所有流量都会通过路由器，即使两台主机实际上位于同一网络上。这显然不是对网络资源的最佳利用，也是为什么设置拆分 DNS 通常比依赖发夹式连接更可取的主要原因。

答案3

您使用的是哪种防火墙？听起来好像没有打开 NAT 发夹功能。

相关内容