路由器 VPN 规则：同时匹配源与目标

路由器的购物页面把 VPN 路由写成一个勾选项，而这个说法掩盖了三个不同的问题。规则匹配的是发送流量的设备、接收流量的服务器，还是两者？两者都不匹配的流量会怎样？当两条规则重叠时，哪一条优先？把答案写成源与目标的组合，就能把含糊的功能清单变成可测试的设计。

功能名称掩盖了两个端点

应使用隧道的媒体播放器是源匹配。应能通过隧道访问的私有办公网段是目标匹配。只需为一项服务使用隧道的工作站则两者皆是，而这个交集正是 大多数消费级固件处理不佳的情形。

在比较产品之前，先把需求写成一对。这对组合就是日后要测试的内容。

提供设备列表或全局目标列表的产品，也许无法表达“只限这台设备、只限这些目标”。差别并非表面：全局目标规则会把每台设备发往该站点的流量都送进隧道，而设备规则会送出该设备的全部流量。两者都不是需求。先用两台设备测试这种情况，再相信界面。

把规则当作交集来构建

表格能让设计保持诚实。把场景放在左边，然后分别写明发送方匹配与目标匹配：

第三行才有趣，因为它同时需要两半。如果固件只能表达一个维度，就必须把需求拆成两条规则，或者移到能够做到这一点的设备上。

保持源身份稳定。DHCP 预留、专用网段或设备身份机制都可以，但租约到期后就会变化的地址不行。要把 IPv6 纳入考虑，因为一个 IPv4 地址无法标识设备的全部流量。

优先级决定重叠结果

规则重叠很正常。宽泛的设备规则和狭窄的目标规则可能描述同一条流，而文档写明的优先级顺序决定哪条胜出。漂亮的设置界面不会告诉你这个顺序。

查阅手册中关于顺序和不匹配情形的说明，然后用你能观察到的流量分别测试两者：

ip rule show
ip route get 203.0.113.10

如果文档没有说明顺序，就假设较窄的规则未必胜出，并据此设计。两条不会冲突的规则，比一条优先级未写入文档的“聪明”规则更容易维护。

名称需要刷新策略

把目标写成域名会带来维护问题。路由器必须解析它、刷新映射、处理多个地址和子域，还要应对绕过预期解析器的应用 DNS。

把一次查询结果复制进 IP 规则只是快照，而不是域名策略。

要决定答案在规则出错之前能有多旧，以及解析失败时路由器会怎么做。保留最后已知地址的规则可能熬过服务迁移；丢弃条目的规则可能悄悄停止隧道。只要写在规则旁边，两种行为都可以接受。

定义不可用状态

路由偏好并不强制流量只走 VPN。隧道断开时，路由器可以阻断流量、直接放行或改用另一条隧道，而每种选择都有不同的故障特征。

确定需求需要哪一种，然后通过断开隧道并观察流量来验证：

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

路由器自身发出的流量属于另一个范围。DNS 转发、更新检查和监控可能从路由器本身发起新的流量，而不是继承设备的源匹配。要显式考虑这些流量，否则它们会以无法解释的泄漏出现在日志里。