一次 k3s 容器无法访问外网分析

问题现象

k3s 边缘集群容器无法与外网建连，现象是发出去的 SYN 包没有收到回复 SYN+ACK 的包，但在物理机上一切正常，ping 和 curl 都可以成功。

经确认，实际上不止这个域名无法建连，其实是容器压根无法访问外网，ping 和 tcp 建连都是不行的，ping 显示 100% loss。

分析过程

首先先解决 ping 都不通的问题，经确认我们用的是 flannel 网络模型，在 pod 内发起目标地址为外网的 icmp 包会依次经经过 pod/eth0 -> cni0 -> node/eth0

于是分别在这三个网卡上抓包，发现 icmp 包正常通过宿主机的 eth0 发了出去，且 eth0 也收到了 ICMP 的响应，但是，eth0 没有将 ICMP 响应包进一步发送给 cni0，pod 中自然是收不到的 ICMP 的响应包，因此 ping 一直都是 100% loss。

正常网络包丢了，本能怀疑是 iptables 规则导致，经过一番查找和对比，没有发现什么异常的规则会丢弃，于是去查看 icmp 的包，之前 tcpdump 没有加 -v，没发现宿主机收到的 icmp 包的 ttl 变为了 1。同时还发现，宿主机回复了一个「time exceed in-transit」的 icmp 消息。

TTL 的设计初衷是为了防止数据包在互联网上无限制地循环下去。每当一个数据包经过一个路由器，该路由器都会将数据包的 TTL 值减少 1。当 TTL 达到 0 时，路由器会丢弃该数据包，并通常发送一个 ICMP "Time Exceeded" 消息给原始发送者。

当 ICMP 或 IP 头中的 TTL 变为 1，意味着数据包要么到达目标，要么经过下一个路由器后被丢弃。

当数据包在宿主机和容器之间移动时，数据包可能需要经过一个或多个网络设备（网桥等），这可能会导致 TTL 的减少到 0，被网络设备丢弃。

比如 flannel 代码为例，在处理包时就有类似的逻辑

那是不是确实经过的网络设备太多，导致 ttl 不够用了呢？在容器内，把 ttl 先改大为 255，在试下，发现回复的 ttl 依然是 1，看来是有什么路由器在把包发给边缘节点的时候，强制把 ttl 改为了 1。

如果是这个问题，那可以通过 iptables 来把宿主机收到的 ttl 改大一点，比如改为 64。

iptables -t mangle -A PREROUTING -p icmp --icmp-type echo-reply -m ttl --ttl-eq 1 -j TTL --ttl-set 64

改完 ping 命令就都可以成功了。

那 ping 能成功，是不是 tcp 请求就能成功呢？

会发现 telnet 和 curl 都会超时，此时再来抓包看看。

发现 tcp 包里的 IP 头里的 TTL 也被设置为了 1。IP 头的 TTL 变为 1，不会把包继续传给容器内下一跳，容器就收不到服务器回复的 SYN+ACK 了。

于是我们再通过 iptables 将 IP 头的 ttl 也设置为 64。

iptables -t mangle -A PREROUTING -m ttl --ttl-eq 1 -j TTL --ttl-set 64

再次请求就成功返回了。

小结

目前为什么 ttl 被设置为了 1，还需要跟边缘节点部署方确认。暂时可以通过此方法 hack 绕过。

iptables -t mangle -A PREROUTING -p icmp --icmp-type echo-reply -m ttl --ttl-eq 1 -j TTL --ttl-set 64
iptables -t mangle -A PREROUTING -m ttl --ttl-eq 1 -j TTL --ttl-set 64

另外，上面 iptables 规则的改动，重启会丢失，需要做持久化。