把 VPN 地址加入白名单仍被拦截？顺着链路追查

把 VPN 应用显示的地址加入白名单，很少能修好被拦截的端口，数据包本身会说明原因。防火墙并没有无视你的规则；它在评估一个客户端界面上根本看不到的源地址。在目标回报这个值之前，每一次改规则都只是猜测。

从真正到达服务的那次请求入手。隧道地址、出口地址以及两者之间的任何地址转换，在目标确认其中之一以前都只是假设。

应用里显示的地址并不是到达服务的地址

一条 VPN 连接至少涉及四个值得分别命名的地址：服务器端点、分配给你客户端的内部隧道地址、本机 Wi-Fi 或以太网地址，以及流量离开服务商后网站看到的公网地址。客户端窗口可能只显示第二个。给规则命名之前，先把四个都叫清楚。使用分离隧道时，发往公网目标地的请求可能完全绕开隧道，所以失败的那次会话并不是用户以为在用的那次。

先确定规则要放行这四个地址中的哪一个，再从对端去验证。如果需求确实是一个办公地址，那么条件就是路由加上该站点的出口安排，而一条标着 Office VPN 的连接本身并不提供这两者中的任何一项。

跟踪一次请求走到它的过滤边界

确认客户端使用的目标地址和端口，再检查这个目标是否真的走你假设的路径。已发布的容器端口、反向代理或端口转发，都可能把判定挪到一台你从未改过的机器上。这些环节各自都可能带独立的策略。先把路径查清，就不必去修一条根本没有数据包到达的规则。

在获授权的 Linux 主机上，改动之前按顺序读取生效规则。转发和容器服务常常跳进自己的链，因此既要看跳转目标，也要看最终判决。

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

在工单里写明命中的规则编号。没有编号，下一位读者无法判断是哪次改动改变了结果。没有时间戳的规则编号依然含糊。

用一次范围受限的抓包验证路径

一次无害请求加一次窄范围抓包，就能裁定这个反复出现的问题。按目标端口和正在排查的主机过滤，限制包数，请求一结束就停止抓包。

tcpdump -ni any 'tcp dst port 9443' -c 20

把三个值并排对比：抓包里的源地址、命中规则所写的源地址，以及应用记录的拒绝。三者可能各不相同，只有第一个能解释由 IP 规则判定的丢弃。被转发的 HTTP 头属于代理层，引用该头的日志描述的并不是防火墙评估过的源。

读链的次序，而不只是规则

iptables 参考手册记录的是有序遍历，因此位于命中终结拒绝之下的放行永远救不回数据包。先前已建立的连接也可能与新连接表现不同，所以旧的成功说明不了新规则。先在你的放行之上找到拒绝或丢弃，再判断放行是否写错。每条规则的计数器还会告诉你哪条规则看到了这个包。

为了看会发生什么而删掉规则，是变更而非观察。读计数器，记下规则编号，并把原策略留在变更记录里。如果测试无法避免，就在链的副本上做。

改动由所有者控制的规则

只更新预期的源地址与服务策略，并通过其所有者来改。共享的转换出口可能同时代表许多用户，放行该地址并不能证明任何人的身份，背后的应用权限也原样不动。

当地址持续变动时，持久的答案是固定出口或经过认证的通道，而不是更长的例外清单。记录观察到的源、目标端口和规则编号。