将一台分支子网的流量经总部 SonicWall 互联网出口路由出去

分支的电话应当从总部出去，而分支的笔记本电脑继续使用本地 WAN，仅靠路由策略无法做到这一点。分支路由可以选择隧道，但隧道策略必须接受该流量，总部必须转发并转换它，响应还必须原路返回。这三者缺一，症状就会是在隧道保持连接时恰好失去互联网的那一部分客户端。

从选择器开始，而不是从路由开始

路由策略按源匹配，因此在做其他任何事情之前，源必须稳定。把选定的设备放进由管理员维护的地址组，或者更好，放进成员资格随设备角色而变的专用网段。当常规 DHCP 变动可能把匹配到的地址移到另一台机器时，策略会静默地选中错误的客户端，而第一份报告通常关于浏览变慢，实际上却是绕路。

用它所服务的策略来命名该组，而不是用楼层或部门，因为路由规则会比两者都活得久。记录其中有哪些设备，以及谁可以添加一台。

添加分支策略，然后守住它的顺序

在分支 SonicWall 上，路由策略选择源组、指定预期目的地并把隧道接口设为网关，受支持的隧道接口设计正是为此而存在。把本地和私有目的地的规则放在宽泛的互联网规则之上，因为先匹配者胜出，而被推进隧道的私有前缀到达总部后只会被丢弃。也要保留防火墙自身通往其 VPN 对端的路由，否则隧道传输会遵循它所依赖的策略。这些都不强迫你转换每一条现有的基于策略的隧道；隧道接口只是若干受支持选项之一。

顺序是最容易因失误而改变的部分。任何添加例外的人都必须把它插在宽泛规则之上，而任何编辑宽泛规则的人都可能一次保存就颠倒整个设计。把预期顺序写在策略旁边，并在固件更新后重新核对，因为接口命名和策略渲染确实会随版本变化。

在总部把路径走完

总部的隧道策略必须接受分支路由现在选中的流量。限定在总部私有 LAN 的跨办公室选择器并不是允许承载任意公网目的地，因此策略需要分支源以及你真正想要的目的地范围。随后总部按自己的访问规则把到达的流量转发到其互联网上行链路，而 SonicWall 的中心出口示例包含在中心 WAN 对远端网络做源转换。没有这项转换，远端看到的是一台私有分支地址，并且没有返回它的路由。

响应是这份约定的另一半。它们必须经由隧道或为其创建的状态化转换返回，而私有站点流量可能需要与公网出口不同的 NAT 处理。让这些规则保持可区分，因为一条掩盖所有内部源的宽泛转换规则会让之后的日志记录和排障难读得多。

决定隧道断开时该组怎么办

如果中心出口是硬性要求而非偏好，那么即使用户仍在线，回落到本地 WAN 也算合规失败。SonicOS 把丢弃隧道接口的路由记录为阻止选定流量走非预期替代路径的受支持做法。

让该路由的范围和优先级与已安装版本相匹配，并通过断开隧道来测试它，而不是相信标签。绝不能本地出网的组应当以关闭方式失败，而更看重可用性的组可以合理回落；两者都是决定，也都不应默认发生。

从三台客户端验证，然后干净地回滚

向中心网关发 ping 测的是错的东西，因为它源自防火墙而非选定的客户端。改为从设备上测试，并测试三台：一台选定设备、一台应留在本地的普通设备，以及一台依赖本地服务的设备。

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

比较公网请求实际从何处出现。选定客户端应当经总部出口到达互联网，普通客户端在远端仍应呈现分支自己的地址；203.0.113.10 是一个文档用地址，用来代替你真正关心的目的地。把 DNS 也放进同一轮，因为查询分支解析器的客户端可能产生源自路由器、源不同的查询，从而走不同的路由。

回滚就是保存的策略顺序加地址组。恢复先前的顺序，把该组从策略中移除，并重新测试两类设备。把导出的配置与变更记录放在一起，因为下一位工程师需要知道在有人编辑之前哪条规则是宽泛的那条。