VPN 服务器：云防火墙与主机防火墙的分工

在云策略中放行 VPN 端口，握手仍可能死在实例上：客机跑着自己的过滤器和自己的监听绑定，任一环节都能丢掉云已放行的流量。反过来也成立：主机规则放行了端口，上游策略却先把它丢掉。两个归属方、两套规则、一条报文路径。与其在最可疑的一层猜，不如按顺序走一遍。

从边缘开始向内排查

顺序是固定的：公网端点、资源网卡、绑定的云策略、客机地址、进程监听、本机入站规则。每一层要么把报文放过去，要么就终止排查，所以从客机开始查最浪费时间。

转发出去的客户端流量是另一个环节，要在隧道解封装之后再看。云层只看到外层隧道，因此它可能放行了一条连接，却与内层服务请求毫无关系。隧道能连上却到不了内部主机，通常指向转发问题，而不是端口被关。

先读云策略，再动客机

确认 VPN 端口的入站规则、协议，以及与你测试客户端匹配的源范围。还要看子网访问控制列表：那是第二道过滤器，有自己的规则和默认值。两者都放行，报文才到得了实例。一边放行、另一边拒绝，正是这个故障的常见形态。

把范围收到有意义为止。对全网开放 VPN 端口容易证明、难以辩护；而钉死在一个地址上的规则，测试客户端一换网络就失效。记下规则标识和策略归属方，下一次改动才能追到人。

先确认监听，再看入站链

在实例上确认 VPN 进程确实绑在你预期的地址和端口上，例如用 ss -lntp 'sport = :1194'。只绑 127.0.0.1 的守护进程会接本地客户端，但隧道里一个也接不到，从外面看和端口被过滤一模一样。

再用你改规则时会用的语法读本机规则，例如 iptables -S INPUT 或 nft list chain inet filter input。写进文件却从未加载的规则，或没有匹配放行项的默认丢弃，都会悄悄丢掉报文。做转发网关时还要看转发与反向路径设置，它们决定经由实例路由、而非发给实例的报文会怎样。

一层有状态，下一层无状态

安全组记得自己放行过的流，并把回应放回来。子网访问控制列表和许多主机防火墙不保留这种状态，于是只覆盖出方向的规则会放过请求、丢掉回应。没有读过第二层的规则，就不要在层与层之间套用回程流量的假设（second layer's rule）。

比对账号里每条规则更快的是看计数器。计数器在涨，说明报文到了并在那里被丢弃；一直是零，说明根本没走到那一层。规则带计数器加载时，iptables -vnL INPUT 与 nft list ruleset 会显示这些数字。

用全新会话测试，别用还活着的会话

比对视图时不要动源网络和测试配置，每次改动后都新开一条连接。能打开 443 的 Web 控制台，和 VPN 守护进程是否绑在 1194 上毫无关系，所以要测你真正需要的端口。已存在的会话在这里是最差的证人：所有新登录都被拒，它却还在工作。

改远程策略之前，先留一条不依赖你正在改动的那条路径的回头路。然后另开一个管理会话，与 VPN 测试并行：早建立的会话可能比拦住新会话的规则活得更久。把两个策略归属方都记下来，免得重建只恢复半条路径；若两层都放行而隧道仍不通，就到客机网卡抓包，确认客户端真正使用的地址和端口。