This issue is not limited to a specific configuration.
I have tested both Mihomo and Sing-box.
When using TUN mode on Linux, it affects running containers, making their mapped ports inaccessible.
Stopping TUN mode restores normal access.
预期:
docker pull 通过tun模式(当前如此);
docker build 通过tun模式(当前如此);
docker run的容器映射的端口可以被外部主机正常访问(当前不可用);
容器内部最好可以通过主机的tun模式。
网络上其他同样问题:
Reference 1
Reference 2
外网访问内网 docker 问题
也可以说外网访问局域网内机器(非网关机器)的问题。我们这样配置好后,会发现无法从外网访问内网的 docker 服务(设置路由器端口转发)。可以通过手机流量访问测试。
我是参考该 github issue 受到了启发,最终解决了。
跳过 docker0 的 ip 范围。即跳过 docker 服务的出站数据包
sudo iptables -t mangle -A clash -p tcp -s 172.18.0.0/16 -j RETURN
然后以下是个人的推测,可能有误,仅供参考。
首先手机入站数据包经过路由器,NAT 到 docker 服务(网关机器)上。此时因为 dest ip 是内网 ip,clash 链 会跳过。DOCKER 链 接手处理,通过 DNAT 转发到了 docker0 bridge 网卡上,这几步都很正常。顺利到达 docker 容器。
随后是 docker 容器的出站数据包,此时数据包会从 docker0 bridge 发到宿主机的物理网卡 eth 网卡。这时数据包之于宿主机来说,是一个入站数据包。数据包会经过 PREROUTING 链,jump 到 clash 链,而此时的 dest ip 为手机的 ip 。会被转发到 clash 上处理,但这个数据包只在出站时转发给 clash 处理。入站的时候跳过了。估计 clash 无法处理这个数据包,可能就丢弃了。就出现了外网无法访问内网 docker 容器的问题。
所以根据 source ip 判断, 将 docker 容器的数据包也跳过。跳过后就解决了~