【发布时间】：2017-02-06 19:43:24
【问题描述】：
我在 NAT 后面有几千台设备与两台服务器通信。每台设备都位于本地路由器（想想调制解调器/路由器）后面，在该路由器上它们被 NAT 到拥有数千个此类设备的专用网络，并且在此专用网络的网关处，来自这些数千个设备的 TCP 会话会发生 NAT 过载/对单个全局 IP 地址上的端口动态 PAT。这意味着，假设设备 1 将与服务器通信，并且连接将来自 global_ip_of_the_router:port_number_1。一旦设备 1 完成通话并移除 NAT 关联，当设备 2 想要与同一台服务器通话时，远程路由器可以为设备 2 分配相同的全局端口，即服务器可以看到新的 TCP 连接来自 global_ip_of_the_router:port_number_1
设备本身启动 TCP 连接，对小文件进行 HTTP 发布，断开 TCP 连接，为下一个文件建立新连接等。这对大约 20 个文件有效，之后在 SYN 上，设备只从服务器返回没有 SYN 的 ACK。 ACK 的 ACK 号与 SYN 上的序列号完全不同。设备立即发送 RST，在 1 秒后退出并尝试从同一源端口进行 SYN，仍然只是 ACK，因此它在放弃前一直退出到 3、6、12、24、48 秒。在来自设备的 RST 上，它似乎正在使用 ACK 之后的 SEQ，试图关闭旧连接（从服务器的角度来看）
远程主机是 AWS ELB。以下是我们提出的假设和我们尝试过的假设：
远程路由器必须比目标服务器 (ELB) 更快地处理 TCP 会话并让 NAT 超时并重用全局端口。这可能导致 ELB 处于 TCP_TIME_WAIT 状态，这就是它使用 ACK 响应 SYN 的原因。由于 ELB 的 TCP TIME WAIT 未知，假设它是 Linux 内核中标准的 60 秒默认值，它将匹配远程路由器上的 post-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 本身的某些东西引起的。
【问题讨论】：
-
请注意，跟踪中“TCP ACKed unseen segment”的扩散是因为我过滤掉了所有带有有效载荷的 TCP 数据包以实现机密性（它们与问题无关）。我包含了连接历史记录，以表明该设备在遇到此问题之前在多个会话上发送数据之前没有任何问题。
-
这个问题在服务器故障中比这里更受关注。请张贴在那里。
-
不过，最好不要交叉发布。
标签： tcp server router nat amazon-elb