VPN 客户端与局域网：何时应该使用独立区域

把隧道接口放进 LAN 区域是让 VPN 最快可用的做法，但它通常是错误的默认值。它让远程客户端获得与有线局域网相同的信任，而任务很少需要这样。独立区域只多花几条规则，却能让边界可见。要决定的不是区域是否更好，而是哪三个条件适用于你的网络。

区域名称不加密任何东西，也不认证用户。它只是按防火墙的策略模型把接口归组。

区域归属究竟控制什么

区域在防火墙模型中把接口或流量归组。随后它的 input、output 与 forward 设置分别管辖不同角色。input 是发往路由器本身的流量；forward 是穿过它发往另一台主机的流量。OpenWrt 的区域文档正是因此把 input、output 与 forward 当作彼此独立的设置。

从 VPN 区域到 LAN 区域的放行，并不自动等于反向放行。转发规则是有方向的，允许客户端到服务器流量的规则，并不允许服务器到客户端的会话。能主动连到服务器的客户端，并不是服务器能反向连过去的客户端。

这个区别正是独立区域有用的原因：你可以明确写出每个方向和每个角色。把方向写在每条规则旁边。

决定一：放行 input、forward，还是两者都放

如果远程客户端需要路由器提供 DNS，就只为该服务放行 input。如果它们要访问文件服务器，就放行到该目标的 forward。多数 VPN 设计两者都需要，但用于不同服务。

对每个本地服务都开放宽泛的 input 访问，几乎从来不需要。把路由器管理当作与应用访问分开的决定。如果路由器只需应答 DNS，就写下那一条放行，其余保持关闭。

决定二：远程客户端需要哪些资源

在写规则之前，先列出客户端网段、目标和服务清单。目标清单比信任标签更有用，因为它能扛过一次防火墙迁移。

把管理接口与普通应用访问分开。能访问 wiki 的远程客户端，并不因此需要路由器管理页面或虚拟机监控台。

如果被放行的目标还能继续转发，区域的边界止于防火墙，而不止于目标之后的行为。

决定三：如何证明边界

每次改动后，测试一条被放行的流和一条被故意拒绝的流。证明一个网站能打开，并不能暴露一条意外的宽泛放行。从 VPN 客户端的地址段测试，而不是从 LAN 测试，并把预期失败的方向也纳入。把两个结果都记录在规则旁边。

在修改远程区域策略之前，先保住网关的恢复通道。使用持久化的受管配置，而不是运行时修改，否则下次重启会把旧信任恢复回来。把上一份配置复制到设备之外，是你所能拥有的最便宜的退路。

网络增长时，记录成员归属与规则用途。新接入的接口不该仅仅因为有人给了它一个方便的区域名，就继承权限。