从 VPN 到 VLAN 的访问：先建矩阵，再写规则

从矩阵开始，而不是从防火墙语法开始。一张一侧是角色、另一侧是服务的表格，可以由应用负责人审阅、由安全负责人争论、由掌握网关的人实施。这种审阅比调试没人达成一致的规则更便宜。

写一小时，之后能省下一周的规则考古。设计谈的是谁能到达哪个服务，而这正是重新编号后仍然保留的部分。

步骤 1: 先给角色命名，再谈网络

从人开始，而不是从交换机开始。写下每个远程接入的群体，以及描述该群体做什么的一句话，例如查看库存水平的仓库员工，或维护一个集成的承包商。如果两个群体将获得相同的访问权限，对这个目的而言它们就是一个角色。

如果某个角色只是因为组织结构图而存在，就停在这里。没有自身服务需求的角色会变成一行相同的单元格，而相同的行会诱使某人后来为图方便而放行整个子网。按人们做什么来划分，而不是按谁签他们的报销单来划分。小办公室通常六个角色太多，三个往往是对的。

步骤 2: 把每个单元格变成一个服务声明

写着“应用程序”的单元格无法验证。写着“从员工池到 443 上 ERP 主机的 HTTPS”的单元格可以验证。把每个网络名替换成目的地、协议和端口，然后加上服务赖以工作的依赖，例如内部解析器或身份提供方。

方向这一列能抓住最昂贵的错误。允许员工打开某个应用，并不意味着允许应用服务器向员工笔记本发起回连，而允许第一个方向的有状态规则常被读成也允许第二个方向。

步骤 3: 决定身份在哪里变成策略

有人必须 把已认证的会话转换成网关可强制执行的角色。受支持的选项包括由认证后端下发的组策略、可信的会话属性，或按角色划分的地址池。三种都可行；客户端发来的标签不行。选择你的网关有文档说明的机制，而不是论坛帖子描述的那种。

分配一个仅仅看起来属于某个 VLAN 的地址，是换了个装扮的同一个非答案。Netgate 关于 OpenVPN 防火墙规则的指南把这层区分讲得很清楚：允许隧道建立起来，与允许流量穿过它，是两个不同的决定。

写下你选了哪种机制，以及它配置在哪里。当角色发生变化时，这条笔记就是一次修改与在三个界面里翻找之间的差别。它也告诉审计人员该先看哪里。

步骤 4: 留意目的地看到的源地址

转发策略必须在边界上与真实源地址一致。如果网关把 VPN 客户端转换成它自己的地址，每个下游防火墙就只看到一个源，从而失去按角色决策的能力。如果它保留客户端地址，那么那个池的返回路径必须存在。

在写最终规则之前，测试两个方向，然后把观察到的源记录在每个单元格旁边。从两个不同角色运行同样的检查并比较结果。如果两者都显示网关的地址，角色的区分已经丢失。一个假定地址被保留、而网关却在做源转换的矩阵，会在第一条下游 ACL 上失败。

步骤 5: 发布之前逐个测试单元格

把每个允许的单元格变成一个代表性操作，把每个拒绝的单元格变成一个否定用例。两者都要从处于真实角色的客户端运行，而不是从网关控制台运行，因为控制台会绕过你正在测试的路径。

# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health

# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22

# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'

能连通的否定用例是一个发现，不是偶然，在规则修好之前它就作为失败单元格留在矩阵里。把测试命令放在表格旁边，让下一位评审者重跑它们，而不是重建推理。

完成的表格比它所针对的网关活得更久。规则随固件和厂商变化，而“承包商能到达一个项目服务”这一行，在这项工作改变之前始终为真。