我在NAT后面有几千台设备与两台服务器通信。每个设备都在本地路由器（想想调制解调器/路由器）后面，在这个路由器上，它们被NAT连接到具有数千个这些设备的专用网络，并且在这个专用网络的网关处，来自这些数千个设备的TCP会话获得NAT过载/ PAT动态地到单个全局IP地址上的端口。这意味着，假设设备1将与服务器通信，并且连接将来自global_ip_of_the_router：port_number_1。一旦设备1完成通话，并且NAT关联被移除，当设备2想要与同一服务器通信时，远程路由器可以为设备2分配相同的全局端口，即服务器可以看到新的TCP连接来自global_ip_of_the_router：port_number_1 < / p>
设备本身启动TCP连接，执行小文件的HTTP帖子，拆除TCP连接，为下一个文件建立新连接等。这适用于~20个文件，之后在SYN上，设备从服务器返回没有SYN的ACK。 ACK具有与SYN上的序列号完全不同的ACK号。设备立即发送RST，退出并在1秒后从相同的源端口尝试SYN，仍然只是ACK，因此它在放弃之前保持退回到3,6,12,24,48秒。在设备的RST上，它似乎是在ACK中使用SEQ跟踪，试图关闭旧连接（从服务器的角度来看）
远程主机是AWS ELB。以下是我们的假设以及我们尝试过的假设：
远程路由器必须处理TCP会话死机并超时NAT并重新使用全局端口比目标服务器（ELB）更快。这可能导致ELB处于TCP_TIME_WAIT，这就是为什么它用ACK响应SYN。由于ELB的TCP TIME WAIT未知，假设它是Linux内核中标准的60秒默认值，它将匹配远程路由器上的FIN / RST后NAT超时。尽管如此，我们在路由器上将其更改为70秒以避免任何竞争条件。这并没有使问题消失。
我们认为，如果远程路由器更快地终止了NAT，它会在设备进行退避时为SYN重试分配新的NAT。如果dest服务器上的问题与远程路由器上使用的全局端口号相关联，那么看到新的SYN来自路由器IP上的新全局端口应该会导致它退出奇怪的状态。现在，虽然我们可以看到这项工作，看起来新分配的NAT端口也在服务器上遇到同样的问题，它返回了一个虚假的ACK，但还有另一个不同的ACK号。
另一个假设是，只有当SYN上的SEQ低于最后一个连接上使用远程路由器上的相同全局端口的序列号时，才会发生这种情况。即，伪ACK上的ACK号总是高于SYN上的SEQ。 （我们将Wireshark切换为绝对序列号来查看）。然而事实证明我们正在看到SYN SEQ大于伪ACK上的ACK号的情况。所以理论就这样了。
我们现在对这里可能发生的事情感到茫然。我们怀疑是新连接获得与旧连接相同的全局端口，但是，如果是这种情况，（a）通过使路由器保持NAT更长时间，它应该阻止它，并且（b）通过使用路由器早先杀死NAT并为同一连接尝试分配不同的NAT，这应该回避问题。
非常感谢您对此行为的任何帮助。
Wireshark跟踪：http://www.filedropper.com/traffictrace-anonymizedandpacketswithpayloadremoved
请注意，跟踪已被匿名化（已替换IP和MAC），并且已删除所有带有效负载的TCP数据包。问题的第一个实例开始于包129，第二个实例包382，然后是463,699,816,1120,1278,1323等。
查看跟踪中的最后一个实例，这是我们缩短路由器上的NAT post-FIN / RST超时的地方。您可以看到前四次，ACK的AKC编号= 2899295595.但是在编号5上，ACK是3102149417.在编号6上，它是4158039292.这是因为在这里，路由器设置为超时NAT更快，所以这些尝试来自路由器上的不同全局端口。如果问题与全局端口和使用全局端口的先前连接有关，则应该已将其停止。但问题仍然存在，这使我们相信这不是源端口相关，而是由TCP SYN本身的某些东西引起的。
答案 0 :(得分：1)
您的路由器是Cisco ASR1001吗？
我遇到了几乎相同的问题，并将ip nat转换超时（动态nat）值设置为默认值（86,400sec）。我以前的超时设置是600秒。
某些客户端在我的NAT网络中进行了一些长时间的TCP会话。就像您说的那样，如果我删除NAT会话的速度快于两个端点，那么它将破坏现有的会话。