☰

Docker 容器内的流量路由不正确——来自 Docker 主机的流量路由正确

tag-icon • tag-icon networking routing docker google-cloud-platform containers
Docker 容器内的流量路由不正确——来自 Docker 主机的流量路由正确

我发现了一个奇怪的问题，来自位于 europe-west1 的 Google Cloud 虚拟机上的 Docker 容器内部、目的地为位于 Amazon Cloudfront 的英国公司的流量被错误地路由到美国，到达加利福尼亚的 cloudfront，从而导致了各种不必要的延迟和缓慢。

$ ping destination.host.co.uk
PING d3csmaahmfmvav.cloudfront.net (54.192.146.219) 56(84) bytes of data.
64 bytes from server-54-192-146-219.sfo4.r.cloudfront.net (54.192.146.219): icmp_seq=1 ttl=49 time=161 ms

但是，来自主机虚拟机的流量正确路由到欧洲 Cloudfront 位置：

$ ping destination.host.co.uk
PING d3csmaafmvavjz.cloudfront.net (54.230.12.31) 56(84) bytes of data.
64 bytes from server-54-230-12-31.ams1.r.cloudfront.net (54.230.12.31): icmp_req=1 ttl=54 time=10.5 ms

在 Docker 容器的网络配置中，我无法找到任何可以表明为什么当主机本身将流量发送到我们期望的位置时，容器会将流量发送到地球的另一端。

我终其一生都无法弄清楚为什么会发生这种情况，希望有人能帮助指出我所忽略的事情。

谢谢！

答案1

啊哈！我终于知道问题出在哪里了。容器使用的是 Google 的公共 DNS 服务器（8.8.8.8 和 8.8.4.4），而 VM Host 在各自的 resolv.conf 文件中使用的是内部 Google DNS 服务器。我（以及设置这些容器的人）犯了一个错误，竟然相信 Google 自己的 DNS 服务器知道 Google 自己的云中的东西到底在哪里。我们真是太傻了！

当我更改容器上的 resolv.conf 以将内部 DNS 服务器置于顶部时，突然间...它不再将流量路由到该死的星球的另一边，因此 ping 时间从 160 毫秒下降到 10 毫秒。所以这还不算太糟糕。

相关内容