我们在 Windows 2008 Server（Hyper-V）上有几个虚拟机，它们之间的路由存在问题。
该设置是 Hyper-V 服务器运行 RRAS 并将其 NIC 上的 IP 映射到虚拟机使用的内部 IP (192.168.1.X)。虚拟机使用 Hyper-V 服务器作为出站流量的网关。这种设置的原因是我们的 ISP 通过 MAC 地址分配 IP，否则虚拟机无法使用分配给服务器的外部 IP。
问题是虚拟机无法使用其外部 IP 地址相互通信。例如，如果服务器 A 是 4.2.2.1（外部 IP）/192.168.1.1（内部 IP），服务器 B 是 4.2.2.2（外部 IP）/192.168.1.2（内部 IP），则无法从 4.2.2.1 ping 4.2.2.2。但可以从 192.168.1.2 ping 192.168.1.1。我们还有一台服务器 C，其地址为 4.2.3.1（不同的子网），该机器可以毫无问题地 ping 服务器 A 或服务器 B。因此，除非这些机器位于不同的子网中，否则它们无法相互通信。
我们不使用 192.168.1.X 进行通信的原因是，为了这个特殊目的，我们正在设置一个监控服务器。该监控服务器将使用 FQDN（如 servera.myservers.net）尝试 ping 服务器 B。因此，我们需要知道是否存在 DNS 故障或其他问题。
奇怪的是，如果您从服务器 A 到服务器 C 进行 tracert，前两次尝试都会超时，然后连接成功，但您却看不到它通过网关。
答案1
我认为 Microsoft NAT 实现存在一个缺陷，许多 NAT 实现（较旧的 Cisco PIXOS、Linux ipchains（iptables 的前身））都存在这种缺陷，即 NAT 只发生在流量上到达在“公共”接口上。思科将这种行为称为“发夹弯”（我猜是因为数据包会“转一个弯”，然后从它进入的接口离开）。
这是一个类似的问题：
一位客户在其网络边缘拥有一台 Cisco PIX，在公共静态 IP 地址和 LAN 之间进行 NAT。他们在 LAN 上有一个 HTTP 服务器，地址为 192.168.1.1，其公共 IP 为 172.18.9.1。LAN 上 PC 上运行的浏览器发出请求“http://172.18.9.1“返回“无法显示该页面”，因为 PIX NAT 实现不会对到达绑定到 172.18.9.1 到 192.168.1.1 的内部接口的流量进行 NAT。
这是一个服务器故障问题，也描述了我正在谈论的行为（尽管再次没有具体引用微软的 NAT 实现）：无法使用公共 IP 地址从同一 LAN 上的主机连接到 NAT 服务器
我相信您在 Microsoft 的 NAT 实现中看到了类似的行为，但我没有确凿的证据（即 Microsoft 的文档）。我手头没有资源来启动测试机器，而且 Microsoft 似乎没有在其文档中使用“hairpin”关键字来表示正面或负面。
（实际上，我发现这很有趣，在我上面提到的 Server Fault 问题中，人们认为缺少“发夹弯”是“正常的”。Linux iptables 可以毫无问题地处理你正在做的事情。我一直认为无法处理这种“发夹弯”的 NAT 实现是低劣的。）