站点间 VPN 该记什么：选择器与作用范围

隧道上线半年后，一个新的子网不再匹配策略，而共享盘里唯一的那份文档只写着“办公室 VPN”。这正是选择器记录要防止的故障，而且它很具体：地址集变了，文档没变。把记录写对，意味着要清楚自己在描述若干地址集中的哪一个，并记录对端实际执行的那个，而不是你配置的那个。

配置的不等于协商的

在基于策略的 IPsec 隧道中，每一侧都会提议流量选择器：子关联的源与目的网段。响应方有权收窄该提议，因此已安装的关联覆盖范围可能小于配置所列。照抄配置的记录描述的是意图，而不是当前的保护范围。两者会悄悄分道扬镳，而隧道状态页上没有任何东西指出这一点。

两列都留着，并写上你观测的日期。配置的选择器是你的本意；协商后的选择器是内核实实在在执行的。当两者不同时，这个差异解释意外故障的次数，远比路由 bug 多得多。

一个关联也不代表所有已配置的配对。含有多种选择器组合的隧道，最终可能得到多个子关联，只列其中之一的记录就是一份残缺的清单。要把它们逐一列出，而不是概括。

基于路由的隧道选法不同

使用基于路由的接口时，由路由表决定什么进入隧道，选择器可以刻意放宽。这是合理的设计而非草率，记录必须照实这样描述。写下路由、它指向的接口，以及限定哪些服务可达的防火墙策略。保护范围是刻意放宽的，收窄由服务范围来完成。

把基于策略的模板套到基于路由的隧道上，产出的文档描述的是这套部署并不使用的机制。下一位工程师于是去找那些本不该存在的选择器，并断定隧道配置有误，其实只是文档写坏了。

地址转换属于同一张表

当 NAT 向对端呈现不同的地址段时，把原始前缀与转换后的前缀记在一起。注明选择器与访问规则在哪一步与它们匹配，因为顺序决定远端究竟能不能看到你写下的地址。只写两个网段之一的表比没有表更糟，因为它看起来是完整的。

NAT 变更后弄坏一条原本正常工作的隧道，细节就在这里：选择器仍匹配原始前缀，对端现在收到的是转换后的前缀，而它的回程路由指向一个已不存在的地址。在两者不再一致的那一刻，没有任何东西记录错误。

私有 DNS 也该记在同一处。一个解析到在该站点无法使用的地址的名字，就是一份附了支持工单的文档错误，而背锅的会是隧道。

附上服务要求

受保护的网段不是权限清单。写下哪些服务应当能从哪个源访问，以及谁拥有它们背后的应用。这两个字段回答的是不同的问题，把它们混为一谈，安全评审最后就会去争论路由而不是访问。

然后写明维护这条规则的网络管理员。没有归属人的选择器清单会悄悄过期，而当隧道在凌晨两点断掉时，过期的和错误的根本分不出来。归属人也是那个能确认变更是有意为之的人。

把记录变成测试计划

对每条必需的路径，选一个代表性的源主机和目的主机，记下预期的路由、服务与回应网关。这就把文档变成了测试计划，而不是描述。用下面的命令读回现役关联，并与你写下的协商那一行对照。

swanctl --list-sas

五行的骨架通常就够让记录保持诚实。下面这版能完整放进变更单，不会被截断：

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

只 ping 网关不是验收测试。它从不走转发路径，所以可能在每条被转发的流都失败时依然通过。要从一侧的主机测到另一侧的服务，并确认回应是经隧道返回的。如果只有 ping 通，那这份记录刚刚抓到了它当初要防的转发问题。strongSwan 关于转发的文档解释了选择器、路由与转发在 Linux 对端上如何相互作用。