公司内网里那台跳板机，内网IP 是外网 10.0.3.17，每次连上去都要先过堡垒机审计，内网再敲一串动态口令。外网我盯着终端里那个永远转不完的内网进度条，心里清楚，外网这条链路只通内网，内网外网连个 DNS 都解析不了。外网可偏偏有个活儿，内网得从内网拉一份外网 API 的外网数据。

第一反应是内网找运维开白名单。运维老张回得干脆：“出口防火墙只放行 443 到指定域名，外网你那个 API 不在列表里，内网加不了。外网” 行吧，内网那就自己想办法。内网机器不能直接出，但内网里有一台装了 Docker 的测试机，版本老得掉牙，Docker 1.13。我翻了翻它的镜像列表，居然有个别人早先拉的 alpine:latest。有镜像就好办，至少不用从零造轮子。

思路很直接：内网机器跑一个容器，容器里跑个反向代理或者隧道客户端，把流量导到外网去。问题在于，容器本身也在内网，它怎么出？答案是它出不去，除非借助一个中间跳板。我手上有一台云主机，公网 IP 是 47.98.x.x，平时用来做测试。云主机能访问外网，也能被内网访问吗？不能，内网没有到公网的默认路由。但内网能访问云主机的内网地址吗？也不能，两个网根本不通。

死循环了。除非——内网里有一台机器同时连着两个网络。我扫了一眼资产表，发现一台开发用的 Windows 工作站，网卡一接内网 10.0.3.0/24，网卡二接了一个 4G 上网卡，IP 是 192.168.8.100。这台机器能上外网。它就成了天然的桥梁。

我在那台 Windows 上开了个 SOCKS5 代理，用了个小工具，监听 0.0.0.0:1080。然后从内网跳板机 ssh 到那台 Windows 的 10.0.3 地址，再通过它的 SOCKS5 代理去访问云主机的 22 端口。链路变成：跳板机 → Windows 工作站 → 4G 外网 → 云主机。绕了一圈，但通了。

接下来就是把容器里的流量塞进这条链路。Docker 1.13 不支持 --network host 以外的花哨玩法，我干脆让容器直接用宿主机的网络栈。在容器里装了个 proxychains-ng，配置指向宿主机的 SOCKS5。然后跑一个简单的 Python 脚本，用 requests 库加上 socks5h 代理去拉外网 API。第一次跑，报错，SSL 证书验证失败。原因是 proxychains 对 HTTPS 的 DNS 解析走了本地，得改成 proxy_dns 并确保 remote_dns_subnet 设对。改完再跑，数据回来了。

整个过程里最别扭的不是技术，是那种“明明有网却要假装没网”的荒诞感。内网安全策略把出口封得死死的，但一台插了 4G 卡的开发机就把墙捅了个洞。老张后来知道了，没说什么，只补了一句：“那台 Windows 下个月要重装，你悠着点。”

我把脚本和配置打包扔在跳板机的 /tmp 下，写了个 cron 每半小时跑一次。数据落盘，再通过内网共享目录同步到数据平台。没人再提白名单的事。外网的数据就这么安安静静地流进了内网，像一条地下河，从防火墙底下渗过去。

后来我拆掉了那台 Windows 上的代理，因为 4G 卡流量超了。换了个方案：用内网一台 Linux 机器做 SSH 动态转发，出口走另一台有双网卡的旧服务器。原理一样，只是更隐蔽。内网穿外网，说到底就是找一条路，让本该不通的两个世界短暂地握个手。握完就松开，别留下痕迹。

(责任编辑：休闲)