When using TUN mode, the ports of Docker containers are inaccessible from the external network
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- docker, linux
- Domain
- devops, networking
Research direction
The report names no repository file, test, or entry point. Start by reproducing on Linux with TUN mode and a Docker container with a published port, then inspect the referenced iptables and Docker forwarding behavior; done means Docker pull and build still use TUN while published ports are reachable externally.
Written by the indexing model from the issue text.
Description
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 容器的数据包也跳过。跳过后就解决了～
- Dominant language
- Go
- Stars
- 241
- Forks
- 243
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SagerNet/sing-tun
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
gvisor: LinkEndpointFilter.Attach never forwards nil, so GVisor.Close leaks all inbound dispatcher goroutines and fdsPossibly taken @arpitjain099 claimed this 53 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Darwin: utun process UUID headers are parsed as IP payloadPossibly taken @d3pre5s claimed this 7 days ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 25/100
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
-
TUN `mixed` stack: TCP never re-injected into tun0 on Linux kernel 7.1 (UDP works, `gvisor` works)Open
Difficulty 4/5 1-2 days Newbie friendliness 45/100
All issues in SagerNet/sing-tun
Similar issues
-
meta
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
last9/last9-mcp-server#443 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
ray-project/kuberay#5454 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
FootprintAI/Containarium#3182 ·
Maintainers usually reply within 1 day
-
bug from-studio
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
esengine/DeepSeek-Reasonix#14608 ·
Maintainers usually reply within 1 day
-
triage
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
getarcaneapp/arcane#4590 ·
Maintainers usually reply within 1 day