Docker网络配置疑难：通过SSTP VPN容器访问内部容器失败的解决方案咨询

你的核心问题出在反向路由缺失和流量路径的源/目标IP匹配逻辑上：

当复用SSTP客户端网络的容器访问内部HTTP服务器（172.17.0.4）时，由于SSTP客户端的VPN默认路由优先级更高，流量会通过ppp0接口发往SSTP服务器（192.168.20.1）。SSTP服务器收到流量后会转发到172.17.0.4，但此时请求的源IP是192.168.20.2（SSTP客户端的ppp0地址）。当172.17.0.4发送响应时，它会根据默认路由把数据包发给Docker网关（172.17.0.1），但Docker网关并不知道192.168.20.0/24网段的位置，因此会丢弃数据包或发往公网，导致响应无法回到SSTP客户端。

另外你执行traceroute时指定了-s 192.168.20.2，强制使用ppp0的源IP，这也会让流量强制走VPN路径，进一步放大了这个问题。

下面提供几个可行的方案，你可以根据需求选择：

方案1：给SSTP客户端添加内部网段的直连路由（最简单） #

既然内部容器都在172.17.0.0/16网段，你可以在SSTP客户端容器中添加一条优先级高于VPN默认路由的规则，让访问这个网段的流量直接走Docker网桥（eth0），不需要经过SSTP服务器：

# 进入SSTP客户端容器
docker exec -it sstp-client bash

# 添加临时路由（重启容器会失效，要永久生效需写入容器启动脚本如rc.local）
route add -net 172.17.0.0 netmask 255.255.0.0 dev eth0

添加完成后，SSTP客户端（以及复用其网络的ab容器）访问172.17.0.0/16的流量会直接走eth0和内部容器通信，公网流量依然走ppp0的VPN路由。

方案2：在Docker主机上添加反向路由 #

如果希望内部容器的响应能正确回到SSTP服务器，你需要在Docker主机上添加一条路由，告诉它192.168.20.0/24网段的流量要转发到SSTP服务器容器（172.17.0.2）：

# 在Docker主机上执行
ip route add 192.168.20.0/24 via 172.17.0.2 dev docker0

这样，当172.17.0.4的响应发到Docker网关（172.17.0.1）时，网关会根据这条路由把数据包发给SSTP服务器，再由服务器转发回SSTP客户端。

注意：Docker重启后这条路由会消失，你可以把它添加到主机的/etc/rc.local或者通过Docker自定义网络配置持久化。

方案3：在SSTP服务器上配置SNAT（源地址转换） #

另一种方法是在SSTP服务器上做SNAT，把来自ppp0接口、目标为172.17.0.0/16的流量的源IP转换成SSTP服务器的eth0地址（172.17.0.2）。这样内部HTTP服务器收到的请求源IP是172.17.0.2，响应会直接发回SSTP服务器，再由服务器转发给SSTP客户端：

# 进入SSTP服务器容器
docker exec -it sstp-server bash

# 添加SNAT规则
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.20.0/24 -d 172.17.0.0/16 -j SNAT --to-source 172.17.0.2

这条规则会对从ppp0过来、发往内部Docker网段的流量做源地址转换，彻底解决反向路由问题。

完成配置后，你可以在复用SSTP客户端网络的Alpine容器中测试：

docker run -it --rm --net=container:sstp-client alpine ash
/ # wget 172.17.0.4

如果能成功下载内容，说明配置生效了。

内容的提问来源于stack exchange，提问作者vanbastelaer