如何限制两个 VPN 互联办公室之间的访问

站点到站点隧道只回答一个问题，即两个办公室能否交换数据包，却把更重要的问题留在那里：哪台分支机构设备可以访问哪项中心服务。把隧道当成互信，访客笔记本就会走到财务服务器同一条路径上。解决办法不是更好的隧道，而是解密之后执行的显式允许清单。本手册把这份清单从定义一路做到可验证的拒绝。

请按此顺序操作，在下面的策略步骤全部通过之前，不要放宽隧道路由。

动网关之前先把矩阵写下来

一行有用的记录要写清三件事：源组、目的主机或服务网段，以及应用实际使用的协议和端口。分支机构和数据中心本身不是条目。私有 DNS 与认证服务只有在应用离开它们就无法工作时，才值得单独成行。

按角色而不是按网段便利来划分源：员工、访客、管理。三者共用一张扁平 LAN 时，网关在网络层无法区分它们，因此必须先做身份控制或分段。然后把矩阵落到文字上，每一行都要有责任人和复核日期。

只允许 IKE 与 ESP 的规则只建立了外层隧道。内层流量以明文到达隧道接口，允许清单正应该放在这里：在解密设备上的转发链、默认丢弃、矩阵每一行一条规则。在 Linux 网关上，这意味着开启转发，并把过滤规则放在隧道设备而不是物理上联链路上，正如 strongSwan 的转发指南所述。

流量选择器是路由决策，不是授权决策。宽泛的选择器覆盖两个网段，对路由来说可能是正确的，而防火墙仍然只允许到一台主机的 TCP 443。选择器是为隧道协商的，它描述的是哪些流量可以进入隧道，而不是某台设备可以使用什么。绝不能因为选择器宽泛就放宽防火墙规则。

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

当分支机构网关在进隧道前把每台主机都转换成同一个地址时，所有基于源的记录都会坍缩成那一个地址。要么停止对隧道流量做转换，要么接受规则必须依赖别的东西，例如转换之前记录的原始源地址。远端也有同样的问题，因为目的主机看到的是 NAT 之后的地址，而不是原始地址。

重叠网段是另一个陷阱。两个都使用 192.168.1.0/24 的办公室，如果不给一侧做映射，就无法写进同一张策略表，而映射并不能替代不冲突的地址规划。在写出以后必须拆掉的规则之前，先把规划改对。

只测试被允许的应用说明不了什么，因为上游某处的宽松规则会产生同样的结果。

从一台普通的分支设备访问目标服务，确认整个会话可用。然后尝试一个必须保持关闭的目的地，例如分支机构根本无权访问的服务器上的管理端口，并读取丢弃它的计数器或日志条目。为了确认规则是否生效而先停用规则集，会让测试失效，还会在你查看期间把网关敞开。

应用会迁移，而比应用活得更久的规则会变成没人负责的缺口。把复核日期挂在对应行上，并在服务更换地址时，用同一次维护同时修改选择器范围和防火墙规则。

隧道之后仍需主机级限制：服务器自身的防火墙只应为本机发布的服务放行分支机构网段。两层彼此一致，比完全信任一层更容易审计。