服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 只能从外部ping内部networking的静态IP
Intereting Posts
Nginx路由到另一个站点 如何在CoreOS上设置docker集装箱联网？ 如何强制AD站点中的机器在自己的站点上对GC进行身份validation 无法打开链接的vCenter Server 如何使用Ansible Tower中的现有Vault文件？ wait_timeout和interactive_timeout之间的区别 IP地址如何分配？ 我如何在Red Hat Linux 4上安装mysql_config？ saslauthdauthentication错误 （Debian）Linux中的重复分区表 只有mod_deflate的声明在TTFB上丢失了400-600毫秒 避免双重redirectNGINX 将服务器上的目录变成可访问的URL？ Nagios发送通知，即使它不应该 Ubuntu中的云：这是什么意思？

只能从外部ping内部networking的静态IP

我正在运行的Ubuntu的，我有Apache运行，但是，我不能内部ping我的静态IP，也不浏览http://207.40.XXX.XX Web服务器使用我的静态IP。 我只能从外部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

任何想法，为什么这是行不通的？

你的NAT网关的行为并不是这样的。 这可能是如何工作的：

平

  1. 您发送一个ICMP Echo请求从192.168.0.5到207.40.123.45
  2. 这路由通过你的路由器。
  3. 您的路由器内的NAT网关将请求重写为207.40.123.45（它是静态IP地址）
  4. 您的路由器回复ICMP回应请求
  5. 由于您的路由器不支持ICMP状态，因此永远不会将ECHO回复传递给您。

HTTP

  1. 您发送TCP / 80连接请求从192.168.0.5到207.40.123.45
  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，但将From：保持不变（192.168.0.120:80）
  7. 你的计算机在192.168.0.5从192.168.0.120得到一个它从未请求的数据包，并将其放在地板上。
  8. 你的联系萎缩，永远不会打开。

请注意，ping失败的原因可能是因为HTTP也失败的原因。 这被称为“NAT发夹”。

你需要的是一个足够聪明的NAT网关，在步骤6它也会重写源地址。

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

在没有发夹的情况下，在通过外部IP地址（207.40.123.45）从本地LAN客户端（192.168.0.5）到networking服务器的HTTP连接尝试期间发生以下情况：

  1. 192.168.0.5发送它的SYN数据包到207.40.123.45，端口80.因为207.40.123.45不在本地networking，这个数据包被发送到默认网关（即路由器）。

  2. configuration为将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在同一个networking上，因此networking服务器将数据包直接发送到192.168.0.5。

  4. 来自192.168.0.120的SYN-ACK分组到达192.168.0.5，但是主机不期望从192.168.0.120得到SYN-ACK，因此被丢弃/拒绝。 192.168.0.5的主机继续等待来自207.40.123.45的应答SYN-ACK，但是当然，这个包永远不会到达。 连接尝试最终会超时，也许经过几次重试，最终，客户端和Web服务器无法build立连接。

这个问题可以通过路由器在步骤2通过应用“发夹式NAT”来解决。 简而言之，解决方法是欺骗客户端和Web服务器通过路由器发送它们的相互通信量。 除了通常应用于端口转发的一个阶段之外，这通过在步骤2应用第二阶段的NAT巧妙地完成。 这是再次的序列，这次是添加了发夹式NAT：

  1. 和以前一样，192.168.0.5将其目的地址为207.40.123.45的SYN数据包（端口80）发送给路由器。

  2. 和以前一样，路由器收到SYN报文，按照configuration的端口转发规则将目的地址重写为192.168.0.120。 然而，这一次，路由器注意到它将把数据包“发夹”回到与之相同的networking上，所以它也将数据包的源地址重写到路由器自己的LAN地址（比如：192.168.0.1 ）。 然后路由器将数据包传送到192.168.0.120的networking服务器。

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

  4. 路由器从networking服务器接收到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的networking服务器通话，而192.168.0.120的networking服务器认为它正在与路由器本身（192.168.0.1）上的客户机通话。 当发夹时，两台主机之间的所有stream量都通过路由器，即使两台主机实际上都在同一个networking上。 这显然是networking资源利用不理想的一个原因，也是build立分离式DNS通常更喜欢依赖于发夹的主要原因。

你使用什么样的防火墙？ 这听起来像NAT发夹没有打开。