我们在Windows 2008 Server（Hyper-V）上有一些虚拟机，并且在它们之间有路由问题。
该设置是Hyper-V服务器运行RRAS并将其NIC上的IP映射到VM使用的内部IP（192.168.1.X）。 虚拟机使用超V服务器作为出站stream量的网关。 这个设置的原因是我们的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.2 .2.1。 你可以从192.168.1.2 ping 192.168.1.1。 我们也有一个服务器C是4.2.3.1（一个不同的子网），这台机器没有问题的ping服务器A或服务器B.所以基本上，除非机器是在单独的子网上，他们不能互相交谈。
我们不使用192.168.1.X进行通信的原因是，为了这个特定的目的，我们正在build立一个监控服务器。 这个监控服务器将使用FQDN（如servera.myservers.net）来尝试ping服务器B.所以我们需要知道是否有DNS失败或什么的。
一件奇怪的事情是，如果从服务器A到服务器C执行tracert，则会在前两次尝试中发生超时，然后发生连接，但不会通过网关看到。
我相信微软的NAT实现会受到许多NAT实现（旧的思科PIXOS，Linux ipchains– iptables的先驱）的伪影，因为NAT只出现在到达 “公共”接口的stream量上。 这种行为的思科主义是“发夹”（我猜是因为数据包发送“发夹”并离开它所进入的接口）。
这是一个难题：
客户的networking边缘有一个Cisco PIX，在公共静态IP地址和他们的LAN之间进行NAT。 他们在局域网上有一个192.168.1.1的HTTP服务器，他们的公网IP是172.18.9.1。 在局域网上的PC上运行的浏览器向“ http://172.18.9.1 ”发出的请求返回“页面无法显示”，因为PIX NAT实现不会将到达172.18的内部接口上的stream量进行NAT转换。 9.1至192.168.1.1。
这里是一个服务器故障问题，也描述了我正在谈论的行为（虽然再次没有特别引用Microsoft的NAT实现）： 无法使用公共IP地址在同一LAN上的主机上连接自动服务器
我相信你看到了与微软的NAT实现类似的行为，但我没有确凿的证据（即来自微软的文档）。 我没有资源来启动一个testing机器，微软似乎没有在文档中使用“发夹”关键字来正面或负面。
（其实我觉得这很有趣，在上面提到的服务器故障问题中，人们认为缺乏“发夹”是“正常的”，Linux iptables会处理你正在做的事情，没有任何问题。总是被认为是不能处理这种“发夹”的NAT实现。）