来自网关 VM 的神秘“需要碎片化”拒绝

我一直在解决严重的 WAN 速度问题。我修复了它，但为了其他人的利益：

通过 WireShark、日志记录和简化配置，我将其缩小到从对内部网络上的服务器执行 DNAT 的网关的一些奇怪行为。网关（一个 CentOS 机器）和服务器都在同一个 VMware ESXi 5 主机上运行（事实证明这很重要）。

这是发生的事件序列 - 非常一致 - 当我尝试使用直接连接到网关 WAN 端的测试客户端（绕过此处通常使用的实际互联网连接）从 DNAT 后面的 HTTP 服务器下载文件时:

1. 通常的 TCP 连接建立（SYN、SYN ACK、ACK）正常进行；网关以两种方式正确地重新映射服务器的 IP。

2. 客户端发送带有 HTTP GET 的单个 TCP 段，这也被正确地 DNAT 到目标服务器。

3. 服务器通过网关发送一个 1460 字节的 TCP 段，其中包含 200 响应和文件的一部分。线路上帧的大小为 1514 字节 - 有效载荷为 1500。该段应该穿过网关但没有。

4. 服务器通过网关发送第二个 1460 字节的 TCP 段，继续文件。同样，链接有效负载为 1500 字节。该段也不穿过网关，也从未被考虑在内。

5. 网关将 ICMP 类型 3 代码 4（目标无法到达 - 需要分段）数据包发送回服务器，引用事件 3 中发送的数据包。ICMP 数据包指示下一跳 MTU 为 1500。 这似乎是荒谬的，因为网络是 1500 字节干净的，并且 3 和 4 中的链接有效负载已经在规定的 1500 字节限制内。服务器可以理解地忽略此响应。（最初，ICMP 已被过分热心的防火墙丢弃，但已修复。）

6. 经过相当长的延迟（在某些配置中，来自服务器的重复 ACK），服务器决定重新发送事件 3 中的数据段，这次是单独发送。除了 IP 标识字段和校验和之外，该帧与事件 3 中的帧相同。它们的长度相同，并且新帧仍然设置了 Don't Fragment 标志。 然而，这一次，网关愉快地将段传递给客户端 - 整体 - 而不是发送 ICMP 拒绝。

7. 客户端对此进行确认，并且传输继续进行，尽管速度非常慢，因为后续段经历大致相同的被拒绝、超时、重新发送然后通过的模式。

如果客户端移动到局域网直接访问服务器，则客户端和服务器可以正常工作。

这种奇怪的行为会根据目标服务器看似无关的细节发生不可预测的变化。

例如，在 Server 2003 R2 上，如果启用了 Windows 防火墙（即使它允许 HTTP 和所有 ICMP），7MB 的测试文件将花费 7 小时来传输，而问题根本不会出现，而且矛盾的是永远不会被拒绝如果禁用了 Windows 防火墙，则首先由网关发送。另一方面，在 Server 2008 R2 上，禁用 Windows 防火墙没有任何效果，但传输虽然仍然受到影响，但比在启用防火墙的 Server 2003 R2 上快得多。（我认为这是因为 2008 R2 使用了更智能的超时启发式算法和 TCP 快速重传。）

更奇怪的是，如果目标服务器上安装了 WireShark，问题就会消失。因此，为了诊断问题，我必须在单独的 VM 上安装 WireShark 以观察 LAN 端网络流量（出于其他原因，这可能是一个更好的主意。）

ESXi 主机版本为 5.0 U2。