我们在 Windows 2008 Server (Hyper-V) 上有几个 VM，它们之间的路由存在问题。
设置是 Hyper-V 服务器运行 RRAS 并将其 NIC 上的 IP 映射到 VM 使用的内部 IP (192.168.1.X)。VM 使用 hyper-V 服务器作为出站流量的网关。这种设置的原因是我们的 ISP 通过 MAC 地址分配 IP，因此 VM 无法使用分配给服务器的外部 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 ping 4.2.2.2 .2.1. 您可以从 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 进行跟踪，前两次尝试会超时，然后是连接，但您看不到它通过网关。
我相信 Microsoft NAT 实施受到许多 NAT 实施（较旧的 Cisco PIXOS、Linux ipchains - iptables 的前身）的影响，因为 NAT 仅发生在到达“公共”接口的流量上。这种行为的思科主义是“发夹式”（我猜是因为数据包进行了“发夹式转弯”并通过它输入的接口离开）。
这是一个类似的问题：
客户在其网络边缘有一个 Cisco PIX，在公共静态 IP 地址和他们的 LAN 之间进行 NAT。他们在 192.168.1.1 的 LAN 上有一个 HTTP 服务器，他们的公共 IP 是 172.18.9.1。来自 LAN 上 PC 上运行的浏览器对“ http://172.18.9.1 ”的请求返回“无法显示页面”，因为 PIX NAT 实现不会对到达内部接口的流量进行 NAT 绑定到 172.18。 9.1 到 192.168.1.1。
这是一个服务器故障问题，它还描述了我正在谈论的行为（尽管再次没有具体引用 Microsoft 的 NAT 实现）：无法使用公共 IP 地址从同一 LAN 上的主机连接到 natted 服务器
我相信您在 Microsoft 的 NAT 实现中看到了类似的行为，但我没有确凿的证据（即来自 Microsoft 的文档）。我没有资源来启动手头的测试机器，而且微软似乎也没有在他们的文档中使用“发夹”关键字来表示肯定或否定。
（实际上我觉得很有趣，在我上面提到的那个服务器故障问题中，人们认为缺乏“发夹”是“正常的”。Linux iptables 可以处理你正在做的事情而没有问题。我已经总是认为不能处理这种“发夹”的 NAT 实现是劣等的。）