为什么按 VPN 状态开关的防火墙入口不是“只允许隧道内 ping”的规则

设想一条防火墙规则：只要某个命名的 VPN 配置文件处于连接状态，就为服务器的公网地址开启 ICMP echo。它读起来像是在说“只能经隧道 ping”，而这种理解错得有实质影响。这条规则并不限制谁能访问主机，它改变的是公共接口在另一条连接碰巧处于活动状态时答什么。这是两种不同的策略，其中一种悄悄扩大了暴露面。

你以为自己写下的规则

原本的需求通常很窄：监控系统，或 VPN 上唯一的管理员，应当能确认服务器还活着。写成一句话时，它听起来像对隧道的访问控制。写成防火墙对象时，它变成了 公共配置文件上的条件，因为 echo 请求正是从那里进来的。

一旦条件变成连接状态而不是源地址，被允许的发送方集合就不再是 VPN 对端集合。任何能到达该公网地址的人，都能在入口打开期间发出 echo 请求。隧道没有成为路径，隧道成了开关。

推广这个想法的人通常并没有谎报他们想要的效果。他们需要一个只在链路健康时才应答的检查，而链路的健康状况最容易通过 VPN 观察。错误在于把可用性信号当成访问决定，然后把它自动化。

入口实际控制的是什么

这种设计把两件彼此独立的事揉在一起，把它们分开就是修复工作的主要部分。第一件是范围：哪个本地地址、哪些远端地址、哪种协议、哪种 ICMP 类型。第二件是条件：规则对象此刻是否处于启用状态。范围是防火墙逐包评估的东西，条件是脚本写进策略存储的东西，两者的核对发生在完全不同的时钟上。

如果需求真的只是 VPN 对端，范围就能回答，完全不需要任何连接状态逻辑：把规则绑定到隧道接口或隧道地址段，把远端地址限制在客户端池内，并指定 echo 类型而不是笼统的“ICMP”。这条规则在没有任何 VPN 时依然正确，也不会被无关的配置文件推开。

如果需求真的是一个公网入口，那就在策略文本里说清楚，因为验收标准随之改变。公网入口必须点名确切的配置文件、定义“已连接”的含义，并声明公网发送方按设计就在范围内。大多数人被迫写下这句话的那一刻，混乱就消失了。

对象只建一次，之后只切换状态

预先建好一条身份稳定的规则，并保持禁用，让控制器只改变它的启用状态。每次运行都按显示名称新建规则，正是策略存储最终留下五个几乎相同的对象、又没有可靠方式删除它们的路径。

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

名称是持久的标识符，显示名称是可以由人编辑的文档。按 -Name 对齐，脚本就不再产生重复对象。同样的命令形态也覆盖 IPv6 情形，配 -Protocol ICMPv6 -IcmpType 128，但那是另一条规则，因为两个地址族的 echo 类型编号不同。

把地址族和 ICMP 类型写明确还有第二个理由：-Protocol ICMPv4 不带类型时会放行该配置文件允许的所有 ICMPv4 报文，包括你从未打算接受的类型。点名类型 8 才能把规则收窄到 echo 请求，而可达性检查发出的正是它。

自动化与初衷相矛盾的地方

每隔几分钟轮询一次客户端配置文件，无法产生即时的边界。在连接断开与下一次轮询之间，规则仍在公网地址上应答；在连接建立与下一次轮询之间，则不应答。承认这段滞后是诚实的，声称设计强制某种严格不变量则不是。

状态检查本身就有范围陷阱。Get-VpnConnection 报告的是本机配置的客户端配置文件，默认针对当前用户，加 -AllUserConnection 则针对所有用户。它不报告当前拨入 RRAS 服务器的远程用户；那是用另一条命令做的另一种观察。建立在错误对象上的入口，谁也连不上。

接着要覆盖没人写脚本处理的状态：上一次运行留下的规则已经启用时启动、入口打开时控制器崩溃，以及规则仍存活而配置文件被删除。每一种都需要一个明确的默认值，而对公网放行来说安全的默认值是禁用。如果需求确实无法容忍轮询窗口，那么状态驱动的规则就是错误的工具，执行点应当放在隧道上，而不是公共接口上。

最后，把公网请求测两次：一次在所选连接建立时，一次在它断开时，并且从一台不在 VPN 内的主机发起。从隧道内部 ping 成功，对这条策略什么也证明不了，而这恰恰是大多数部署跳过的测量。