为什么 VPN 隧道地址不会打开入站端口
隧道地址只是把客户端标识给能够路由到它的对端，从不创建监听器。请依次检查绑定、返回路由，再检查策略。
连上办公 VPN，在 8443 端口启动一个小服务，把隧道地址发给同事，然后看着连接失败，而客户端仍然报告已连接。隧道里没有任何东西是坏的：地址已经下发，会话已经建立，本该承载回包的报文只是从未被放行。按顺序做完下面三项检查，并在失败的那一项停下，因为每项的修法都不同，而且只有一项与 VPN 有关。
先看套接字究竟绑定在哪里
在任何东西被路由之前，必须有进程在调用方能够到达的地址上监听。开发服务器是常见的元凶，因为它们大多默认绑定到 loopback，只接受来自同一台机器的连接。隧道地址并不会改变这个绑定，操作系统会在 VPN 介入之前就拒绝连接。
ss -ltnp | grep 8443
netstat -ano | findstr 8443读本地地址这一列，而不是看状态。127.0.0.1:8443 表示只监听 loopback，修法是绑定到 0.0.0.0 或隧道地址本身。0.0.0.0:8443 会在所有接口上接受连接，当这台机器还有公网地址时，这比多数人想要的更宽；10.64.7.15:8443 是只有同事能到达的地方才监听的窄版本。还要注意同一份输出里的进程名，因为上一次测试残留的实例常会让端口看起来是开的，却用错误的内容作答。
然后问一下，有没有东西能路由到这个地址
隧道地址只对配置了把该前缀送进隧道的对端有意义。同事的机器有自己的路由表，如果没有通往隧道子网的路由，报文就会走默认网关，并死在完全不知道这个地址存在的地方。这是调用方的路由问题，不是你这一侧的许可问题。
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
两台客户端之间的服务器同样重要。常见的远程访问设计里，每个客户端向网关建立出站连接，网关为这些流保留状态，所以回包沿着它已经知道的路径返回。从一个客户端到另一个客户端的连接是一条新流，网关必须接受并转发它；很多部署会故意关掉这一项，让客户端彼此隔离。消费级 VPN 服务通常默认隔离；企业网关有时按组放行。
在改动主机之前先看方向。如果隧道地址能从网关本身应答，却无法从对端应答，差别就在网关的客户端互连设置上，改本机防火墙一点用都没有。
最后，找到放行这条流的策略
在被路由的报文和应答的服务之间隔着三层策略：VPN 服务器的转发决定、主机防火墙，以及实例前面的任何云安全组。三层必须一致，而它们失败的方式各不相同，所以上表里的症状比浏览器里的报错更有用。
主机防火墙是绑定成功后人们最容易忘的一层，因为在 LAN 接口上放行端口的规则，不会自动在隧道接口上放行。按接口限定范围是正确设计，同时也是「办公室能通、家里不通」这类服务的常见原因。要看规则的作用范围，而不是端口号。
有状态过滤解释了相反的情形。从笔记本发出的出站连接会建立状态，回包无需入站规则就能通过。同事的连接是全新的流，后面没有任何状态，因此需要明确放行。正是这种不对称，才使得你本机上正常工作的浏览器会话，对服务能否从外部访问毫无说明力。
一项检查失败时，改设计而不是改隧道
如果需求是让同事打开你本地的服务，诚实的答案通常是专为入站访问设计的机制。反向 SSH 隧道是最小的一种：你的机器向外连接到同事本来就能到达的主机，监听器存在于那台主机上。
ssh -N -R 8443:127.0.0.1:8443 [email protected]中继需要在 SSH 服务器配置里设置 GatewayPorts clientspecified，否则转发出来的监听器会绑在中继的 loopback 上，同事遇到的仍是同样的拒绝。任何比一个下午更持久的方案，带健康检查和已发布名称证书的负载均衡器或 ingress 是更合适的工具；而当两个网络确实需要互通时，为两个子网都配路由的站点到站点隧道才是正确答案。
这些设计都让暴露变得明确，这才是重点。VPN 只是在你本来就有权限使用的网络之间搬运报文，它不发布服务，也不会把笔记本变成面向互联网的主机。任务在于决定改动三层中的哪一层，而隧道很少是其中之一。