VPN 站点扩展：沿网关之后的返回路由

来自分支机构的数据流终止在一个网关上，而该网关的 LAN 并不包含你被要求访问的应用。服务器位于第二个数据中心，隔着 VPN 从未配置过的内部链路。在近端网关上再加一个前缀对这种情形毫无帮助，因为远端网关是加密端点，而不是最后一台路由器。这条路径需要一条去程路由、远端安全边界上的准入，以及目的网络自身内部的回程决定。

远端网关是加密端点

网关到网关的 IPsec 保护两台安全设备之间的流量，内部地址以加密形式穿过那一段。过了远端网关，普通路由接管，包括数据中心之间存在的任何策略。因此受保护的那一段只覆盖旅程的一部分，而不是其余部分。反其道而行之，正是设计最终得到一个健康隧道和一个无法访问的应用的方式。

把路径画成三段：分支机构到近端网关、近端到远端、远端网关到应用。每一段都有自己的负责人和自己的失效方式。

读隧道策略的两个方向

隧道策略通常从本地一侧的视角书写，而部分配置正是来自这个习惯。两端都必须按它们在隧道内出现的样子列出分支机构源和目的，包括设计打算进行的任何转换。只更新近端会产生第二阶段不匹配，看起来像路由故障。在碰任何路由之前，先比较两套策略。

把源和目的写成地址，而不是站点名称。这里的含糊之后会以令人困惑的不对称形式重新出现。

添加去程路由并确认准入

远端网关需要一条通往应用子网的路由，而它们之间的每台路由器都必须放行分支机构源。核实远端网关实际拥有什么，而不是图中所声称的。

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

第一条命令报告远端网关会为该源选择的出接口和下一跳，这是普通路由表无法回答的问题。跟踪显示数据包在哪里停下，而远端网关之后的断裂指向内部传输，而不是隧道。当路由存在而流量仍然消失时，在远端网关上抓包并读取到达的源地址，因为意外地址意味着某处发生了未规划的转换。这里的所有地址都是占位符，因此请替换为真实的分支机构、传输和应用子网。

从分支机构测试，然后重新测试旧路径

验收需要一个真实源，而不是从远端网关发起的探测。从分支机构主机运行检查，并在同一项测试中保留原先可用的目的地。

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

来自应用的响应同时证明去程路径和回程路径，而对旧目的地的 ping 证明改动没有破坏原本可用的部分。记录应用日志中的源地址，因为它的访问规则和任何回程路由都必须与该值一致。在分支机构于隧道之前做转换的地方，策略地址与应用看到的地址按设计并不相同，因此两者都要记录。在密钥更新或路由变更之后重复测试，因为这些路径往往只验证一次就被遗忘。

为三段中的每一段以及目的网络内部的回程路由指定负责人。有四个负责人的路径会在他们之间的空隙中失败。