总结我们遇到了内部 Google Cloud Load Balancer 背后的服务在响应超过一定大小时无法回复的问题。通过一些 tcpdump 和 wireshark 测试，我们发现我们的站点到站点 ipsec VPN 实例无法将 ICMP“需要分片”数据包发送回 GCLB，导致响应陷入 TCP 重传循环。
细节
我们为 GCP VPC 和我们的现场网关设置了站点到站点 IPSec 隧道。我们在该 VPC 中有一些虚拟机实例，并且我们创建了内部 GCLB（Google Cloud Load Balancer）来负载这些服务。但是，我们注意到，当服务的响应超过一定大小时，curl对 GCLB 的请求（来自我们的内部网络）会卡住并最终超时。
我在 GCP 中对我们的 VPN 实例（运行 ipsec 的实例）执行了 tcpdump，并在响应为“大”时捕获了跟踪。事实证明，VPN 尝试将需要 ICMP 碎片处理的数据包发送回内部 GCLB，但收到“无主机路由”的提示。我验证了从 VPN 实例到 GCLB 有路由，我甚至可以在 VPN 实例上 curl GCLB 实例。这让我怀疑防火墙阻止了 ICMP 数据包。
但是，在尝试了 GCP 的防火墙规则后，我还是无法让防火墙规则适用于网络中的 GCLB。似乎所有防火墙规则都适用于 VM 实例。
有人可以解释一下如何解决这个问题吗？
答案1
从主题来看，您的问题是：“防火墙规则可以应用于内部 GCLB 吗？”答案是否定的。防火墙规则直接应用于虚拟机，而不是负载均衡器。内部负载均衡器是直通负载均衡器。要控制流量，您可以将防火墙规则应用于虚拟机本身，但不能将它们“应用于负载均衡器”。您可以查看此文档了解更多信息。
仔细查看您的详细信息后，似乎您可能已配置虚拟机来运行 IPSec 软件，正如您提到的那样“我在 GCP 中的 VPN 实例（运行 ipsec 的实例）上执行了 tcpdump”。我建议他们改用 Cloud VPN，这样您就可以确保正确设置了 MTU 等内容。实例中有很多地方可能存在 MTU 配置错误等问题。
请注意，GCP 中的最大 MTU 为 1460 字节，但 VPN 流量的 MTU 应小于 1460 字节，以考虑数据包封装。您可以查看建议用于使用 Cloud VPN 时的本地网关。
他们应该做的另一件事是在通过隧道发送流量之前对其进行预分片。流量必须在封装之前进行预分片。这是连接到 Cloud VPN 的对等设备所需的配置。以下是文档关联为此。由于您似乎正在运行基于 VM 的 VPN，因此您需要处理其 VM 和对等网关上的预碎片。
我想在这里提一下，Cloud VPN 会为您进行预碎片化，因此唯一需要考虑的就是对等设备。