![无法从内部网络 ping 静态 IP,只能从外部](https://linux22.com/image/534073/%E6%97%A0%E6%B3%95%E4%BB%8E%E5%86%85%E9%83%A8%E7%BD%91%E7%BB%9C%20ping%20%E9%9D%99%E6%80%81%20IP%EF%BC%8C%E5%8F%AA%E8%83%BD%E4%BB%8E%E5%A4%96%E9%83%A8.png)
我正在运行 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 网关的行为不允许这样做。它的工作方式可能是这样的:
平
- 您从 192.168.0.5 向 207.40.123.45 发送 ICMP Echo 请求
- 这将通过您的路由器进行路由。
- 路由器内的 NAT 网关将请求重写为来自 207.40.123.45(静态 IP 地址)
- 您的路由器回复 ICMP Echo 请求
- 由于您的路由器不支持 ICMP 状态,它永远不会将 ECHO 回复传回给您。
HTTP
- 你从 192.168.0.5 向 207.40.123.45 发送 TCP/80 连接请求
- 这将通过您的路由器进行路由
- 您的 NAT 网关将数据包重写为从207.40.123.45:41345 至 207.40.123.45:80
- 您的 NAT 网关注意到有一个端口转发,因此将数据包转发到 192.168.0.120:80
- 192.168.0.120 的服务器回复来自 207.40.123.45:41345 的连接尝试
- 您的 NAT 网关看到回复并将回复中的收件人:地址重写为 192.168.0.5:36311,但发件人:保持不变(192.168.0.120:80)
- 您的位于 192.168.0.5 的计算机从 192.168.0.120 收到一个它从未请求过的数据包,并将其丢弃在地上。
- 您的连接不稳定,始终无法接通。’
请注意,ping 失败的原因可能与 HTTP 失败的原因相同。这称为“NAT Hairpinning”。
你所需要的是一个足够智能的 NAT 网关,它在步骤 6 中还会重写来源地址。
答案2
虽然 1138 的答案是正确的,但我只是想详细解释一下“发夹式 NAT”是什么、它是如何工作的,以及为什么在这种情况下它是必要的。如果你不关心 IP、NAT 和路由的细节,请随意忽略我(相当冗长的)答案的其余部分。
如果不考虑发夹弯,以下是本地 LAN 客户端 (192.168.0.5) 通过外部 IP 地址 (207.40.123.45) 尝试与 Web 服务器建立 HTTP 连接时发生的情况:
192.168.0.5 将其 SYN 数据包发送到 207.40.123.45,端口 80。由于 207.40.123.45 不在本地网络上,因此此数据包被发送到默认网关(即路由器)。
路由器配置为将 207.40.123.45:80 转发到 192.168.0.120:80,将数据包的目标地址重写为 192.168.0.120,然后将数据包传送到 Web 服务器。
Web 服务器收到 SYN 数据包,并向发送者的地址发送一个回复 SYN-ACK 数据包,该数据包192.168.0.5由于 192.168.0.5 位于同一网络,因此 Web 服务器将数据包直接传送到 192.168.0.5。
来自的 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:
与之前一样,192.168.0.5 向路由器发送发往 207.40.123.45、端口 80 的 SYN 数据包。
和以前一样,路由器接收 SYN 数据包,并根据其配置的端口转发规则,将目标地址重写为 192.168.0.120。但这一次,路由器注意到它即将把数据包“发夹”回接收数据包的同一网络,因此它还会重写数据包的源地址到路由器自己的 LAN 地址(例如:192.168.0.1)。然后路由器将数据包传送到 192.168.0.120 的 Web 服务器。
Web 服务器收到 SYN 数据包,并将其回复 SYN-ACK 数据包发送回发送者的地址,这次的地址是192.168.0.1. 因此,答复返回到路由器。
路由器收到来自 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 发夹功能。