为什么封锁 VPN 端口无法阻止未经授权的隧道

防火墙规则只拒绝它匹配到的流量。它并不会拒绝所允许连接的全部用法，而大多数针对未授权隧道的策略正是在这个缺口上失效。封锁五年前流行的那款客户端的端口，会让所有走 443 的流量毫发无损，而且对能够改写自身路由的设备毫无说明。把管控建立在权限和访问目标之上，然后读取你真正放行的流量。

为什么端口清单不是策略

端口是传输层的概念，而好几种隧道技术根本不使用端口。另一些则刻意与普通网页流量共用端口，因为这个端口是保证能通过的。因此，按历史端口设定的规则只会枚举出少数实现，而不是整类行为。它也很容易过时：供应商一改默认值，清单描述的就已经是过去。

更糟的是，成功封掉一个端口会被读成整个问题已经解决，从而推迟那些真正重要的管控。

协议号与端口是不同的命名空间

GRE 分配的是 IP 协议号 47。它不是 TCP 端口 47，也不是 UDP 端口 47，为端口编写的过滤规则碰不到它。ESP 和 AH 同样位于协议号 50 和 51。封装流量还可以藏在一条被允许的连接里，所以分类或特征签名能有帮助，但单凭它永远不能证明用途。置信度与覆盖率属于具体产品和版本，而不属于这个概念。

nft list ruleset | grep -nE 'gre|esp|ah|47|50|51'
cat /proc/net/protocols | head -20
ss -tn state established '( dport = :443 )'

第一条命令显示你实际写下的内容；第二条显示协议栈已知的协议表；第三条显示此刻有多少会话在使用网页端口。它们都没有说明这些会话是做什么用的。TLS 拦截是一个单独的决定，有自己的信任、隐私和客户端兼容成本。它既不是拒绝某个指定目标的先决条件，也不保证能识别隧道。

管控设备拥有的权限

能够更改自身路由表和过滤规则的设备，具备普通应用没有的能力。准入与配置管理正是消除这种能力的手段，而且无论隧道会用哪个端口，它都起作用。

这意味着经批准的接入设备得到的是其申报的角色，而不是替其他设备转发的无限许可；也意味着安装与网络管理权限是策略的一部分，而不是事后补充。

观察留下来的流量。把设备身份、分配角色和流量元数据关联起来，并把分类当作有局限的证据，而不是判决。

conntrack -L | awk '{print $1, $4, $5}' | sort | uniq -c | sort -rn | head
ip -br addr show
ip route show default

长期存在的加密会话或很大的字节数并不是滥用的证据：备份、支持工具和站点互联看起来一模一样。把采集范围限制在调查之内，并在拥有它的流程下保存所发现的内容。

把例外写清楚

每个环境都有一些目标必须保持可达，以用于更新、身份验证和恢复。把它们连同用途和负责人一起写下来，并定期复核，而不是一次次故障后才逐个发现。

当业务确实允许使用某个范围很广的外部服务时，应评估该服务赋予的权限，而不是假定目标标签就让一切用法都可接受。

未经复核的例外就是带工单号的漏洞。有名称、理由和复核日期的例外才是一项决定。

用书面方案验收，而不是口号

验收有两半：已批准的工作仍然成功，具体的禁止情形在授权测试中失败。两者都必须在变更前写下来，并在变更后重跑。

把终端和策略变更也纳入这次复核，因为笔记本上加的一条路由可能让边缘上原本完美工作的过滤规则失效。

交付物是一条有归属的出口边界，并附一份已知的剩余风险清单。声称关掉几个端口就终结了未授权 VPN 使用，并不是这样的交付物。