VPN 用户需要的是一台打印机，而不是整个局域网

规则看起来没错，打印机却仍然拒绝。或者打印机通了，同一个用户还能访问文件服务器，这更糟。两种结果通常出自同一处：狭窄规则被加进了一组早已放行更宽范围的规则里。读一遍实际生效的顺序，就能在新规则写下之前解释这个结果。

症状：狭窄规则没有带来任何变化

一个专用 VPN 地址池、一个打印机地址，以及一条 TCP 631 的放行规则，是合理的设计。当它完全没有变化时，首先该怀疑流量从未到达这条规则。规则只对到达其评估顺序位置的流量作出决定。字段很容易核对，也很少是失败的原因。

相反的症状更容易被忽略。打印任务成功，同时对该用户本不该访问的文件共享的连接也成功。这说明更早的某条规则已经放行了局域网。

两种症状都指向顺序，而不是新规则里的字段。一种是从未匹配的规则，另一种是匹配得太早的规则。

流量实际命中哪一组规则

pfSense 按接口评估规则，而 OpenVPN 有自己的选项卡，其规则对每个服务器和客户端实例都生效。这些规则先于分配给某个具体 OpenVPN 接口的规则被处理。因此，留在 OpenVPN 选项卡上的宽泛放行同样适用于该用户，无论接口选项卡怎么说。把这个顺序抄进变更记录，评审就能不开 GUI 也核对。

这就是新的狭窄放行无法收回权限的原因。防火墙规则只增加许可，不会从更早的匹配中拿走它。

从上往下读实际生效的列表，在第一条与流量匹配的规则处停下。那一次匹配就是决定，它下面的所有内容对该流都不可达。

从打印任务出发写这条放行规则

从任务出发，而不是从打印机出发。用户需要打印机地址上的打印服务，因此规则要写明那个地址、那个协议和那个端口。给 VPN 地址池一个别名、给打印机一个别名，规则才读得懂。

不要为了让向导更高兴而加上发现或管理端口。放行整台打印机与放行一个打印队列，是两种不同的策略。

保留打印机自身的认证。网络放行不能替代它。队列级账号才是决定谁能打印什么的正解。

六个值承载了全部意图：动作是放行，地址族是 IPv4，协议是 TCP，源是地址池别名，目标是打印机别名，端口是 631。超出这六个的任何东西都是另一种策略。

在没有局域网放行的情况下给客户端一条路径

客户端需要一条到打印机地址的路由，办公侧需要一条回到 VPN 地址池的应答路径。只推送一条 /32 能让客户端配置保持狭窄，便于排障。它不是授权边界，因为客户端可以自己添加路由。

如果队列以名称寻址，就把解析器依赖单独定义。为了让一个名字能被解析而放行整个局域网，代价远大于任务本身。

在回程路由到地址池和源地址转换之间有意做选择。两者都可行，各自向日志隐藏的东西不同。

除了任务，也要测拒绝

先从 VPN 用户提交一个小而不敏感的打印任务，再尝试一个本应被拒绝的局域网资源，以及防火墙自己的管理页面。三项测试属于同一次会话，因为这是整体看清策略的唯一办法。仅有一次成功的打印任务，几乎证明不了边界。

在把部署称作“仅打印机”之前，复查 IPv6 和其他任何处于活动状态的 VPN 路径。在一个地址族里狭窄的规则集，在另一个地址族里可能完全敞开。