我们有一个新的 Google Cloud Platform 设置。我们已成功创建与办公室路由器的 VPN 连接。我们可以从办公室访问 Google Cloud 中的私有地址，并且 GCP 内部的一些服务可以访问我们的办公室网络。我们已设置 kube-dns 以通过 VPN 使用我们的内部 DNS 服务器来访问私有资源，并且在大多数情况下，它运行良好。并且，从容器和容器集群节点虚拟机，我们都可以 ping 办公室网络内的地址。
但是，我们希望在 Google Container Engine 中部署的第一个应用程序需要 HTTPS 访问防火墙后面办公网络内运行的 API 服务器。这些 HTTPS 连接（使用 wget 和 curl 测试）只是挂起。没有返回任何数据。我在办公室路由器上进行了流量捕获，我可以看到数据包按预期进入和返回隧道。我还尝试了从 Google 到我们办公室的常规 HTTP 和 SSH 连接。我尝试从正在运行的容器内部和容器引擎集群节点（COS 映像）本身进行连接。除了 ping 和 DNS 之外，Google 无法进入办公网络。
GCP 中没有出口防火墙规则。办公室路由器策略目前允许所有流量通过 VPN。我发现了其他几篇与我们的情况类似的帖子，但它们比较旧，其中大多数都提到了在此期间对 GCP 进行的修复，其他帖子讨论了复杂的 iptables 解决方案。
所以，我们在第一次云部署中完全受阻。我们如何排除 GCP 中的网络故障？返回的数据包似乎没有被路由回其源。DNS 和 ping 都不是 TCP，当然 HTTPS 和 SSH 也是 TCP。这是我能识别出哪些有效哪些无效的主要区别。我们接下来该尝试什么？
答案1
以下说明 Google Cloud VPN 所需的 MTU 设置。
https://cloud.google.com/compute/docs/vpn/advanced#maximum_transfer_unit_mtu_considerations
在我们的 Juniper SSG 系列路由器上，我使用以下命令在 VPN 隧道虚拟接口上设置 MTU：
set interface tunnel.3 mtu 1460
但是，该解决方案需要的不仅仅是 MTU，因为在 VPN 上，在将数据包分解为 MTU 大小的片段后，加密会增加开销，至少我认为是这样。同样，在我们的路由器上，我们必须应用以下配置命令来为 VPN 流量配置适当的数据包大小：
set flow tcp-mss 1350
set flow vpn-tcp-mss 1300
我没有花时间在这些命令中寻找完美的数值，也没有测试是否实际上只需要其中一个，但设置这两个值后，我们的 VPN 开始按预期工作。