我有一个在 Azure 云中运行 Windows Server 2012R2 的虚拟机。该机器静态分配其专用和公共(public) IP 地址。在那台机器上，我正在运行客户端应用程序(具体来说是 Jenkins Agent)。此客户端打开与其服务器(Jenkins Master)的 TCP 连接，该服务器在 Azure 云外部运行(在某个公共(public) IP 地址后面)。 TCP 连接建立良好。
为了保持此连接处于事件状态，客户端和服务器每 4-5 分钟就会互相“ping”一次。这种“ping”是通过通过打开的 TCP 连接交换多个 TCP 数据包来完成的。
经过一段随机时间间隔后，客户端无法再连接到服务器，服务器也无法再连接到客户端。因此客户端和服务端都会抛出连接超时异常。
为了分析该问题，我跟踪了与 Wireshark 的通信，该通信在 Azure 云中的 Windows Server 上运行(客户端应用程序在其中运行)。虽然通信运行良好，但 Wireshark 显示 TCP 流量在以下各项之间交换: - 客户端的私有(private) IP 地址/本地端口 - 服务器的公共(public)IP地址/端口
这似乎完全合乎逻辑，因为 Azure 计算机(客户端)不知道其公共(public) IP 地址和公共(public)可见端口(应用 NAT 后)。
当问题开始发生时，我看到客户端和服务器都在发送 TCP 重传数据包，这意味着它们都没有收到先前发送的 TCP:PSH 数据包的 TCP:ACK 数据包。最奇怪的是客户端机器正在从服务器接收这些 TCP 重传，但问题是:这些包没有发送到客户端的私有(private) IP/本地邮件。这些包在 Wireshark 中显示为发送到客户端的公共(public) IP 和公开可见的端口!显然，客户端应用程序不会收到这些包，因为机器的 NIC/驱动程序会丢弃它们(这也是预期的)。
问题:有谁知道为什么发送到 Azure 计算机(客户端)公共(public) IP 地址和公共(public)可见端口的 TCP 响应有时会到达计算机本身，而无需将 NAT 转换应用于该内容？!
最佳答案
经过 3 天的状态跟踪，没有发现问题再次发生!所以我用结论来解决这个问题:更频繁的客户端/服务器 ping(即保持连接事件)肯定可以解决这个 Azure 问题。
关于Azure VM 出站 TCP 连接在几分钟后中断，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45980516/