Junos 双 WAN IPsec VPN：把源路径对上正确的网关

面向双 WAN IPsec 的 Junos SRX 实操：把每个本地源与其候选网关配对，然后证明到底是哪条关联承载了流量。

每个站点两条 WAN 链路看起来像冗余，直到你要证明某个具体流量究竟用了哪一对地址。在 SRX 上，一个 IKE 网关只承载一个外部接口和一个本地地址；远端候选列表并不会变出第二个本地源。所以这篇从配对矩阵讲起，而不是从配置讲起，因为 Junos 会毫不犹豫地 commit 一个只覆盖了预期组合一半的设计。我在两台 SRX345s 上踩到过：备份隧道干净地起来了，回切时却把会话拖下了水。

按顺序走完这些步骤：先列出必须支持的配对，再为每个本地源建一个网关，确认是哪条关联承载了流量，最后才决定每类故障允许改变什么。

在碰 CLI 之前先把配对画出来

如果 A 站可以从 A1 或 A2 出，B 站可以在 B1 或 B2 上收，那么外层地址就有四对。多数设计持续需要其中两对，另外两对按可选处理。把矩阵写下来并给每一行打标记，因为你承诺的每一行后面都要付出一个网关、一个隧道接口和一条路由判断。

Local sourceRemote candidateRequired?
A1, ISP1 addressB1steady state
A1, ISP1 addressB2decide explicitly
A2, ISP2 addressB1decide explicitly
A2, ISP2 addressB2backup path

每个必需的配对要同时满足三件事：这些地址之间可达的 underlay、两端互相接受对端身份与源地址，以及受保护的返回路径。只在一个方向通的配对照样能显示隧道，故障会在后面以应用单向流量的形式冒出来。

按本地源划分网关，而不是按远端站点

远端地址列表属于一个网关，本地源也是。IKE 网关参考把远端地址、外部接口、本地地址和死对端检测分别当作独立设置，这正是要点：两个本地源就意味着两条 st0 单元上的两个网关。共享 IKE 策略没问题，但留一个网关指望它自己换源就不行。

set security ike policy IKE-P1 mode main
set security ike gateway GW-A1 ike-policy IKE-P1
set security ike gateway GW-A1 address 198.51.100.20
set security ike gateway GW-A1 address 198.51.100.21
set security ike gateway GW-A1 external-interface ge-0/0/0
set security ike gateway GW-A1 local-address 203.0.113.10
set security ike gateway GW-A1 version v2-only
set security ike gateway GW-A2 ike-policy IKE-P1
set security ike gateway GW-A2 address 198.51.100.20
set security ike gateway GW-A2 external-interface ge-0/0/3
set security ike gateway GW-A2 local-address 192.0.2.10
set security ike gateway GW-A2 version v2-only

接着把隧道接上，给远端前缀两个下一跳，每条隧道一个：

set interfaces st0 unit 1 family inet
set interfaces st0 unit 2 family inet
set security ipsec policy IPSEC-P1 perfect-forward-secrecy keys group14
set security ipsec vpn VPN-A1 bind-interface st0.1
set security ipsec vpn VPN-A1 ike gateway GW-A1 ipsec-policy IPSEC-P1
set security ipsec vpn VPN-A2 bind-interface st0.2
set security ipsec vpn VPN-A2 ike gateway GW-A2 ipsec-policy IPSEC-P1
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.1 preference 10
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.2 preference 20

一个网关能不能挂两条 address 语句，取决于版本和这台设备跑的是哪个 IKE 进程。基于 kmd 的旧 Junos 每个网关只接受一个远端地址；新版本能处理多个候选，但会加上自己的限制，高可用集群就是这种支持变窄的常见场景。从旧机箱照搬之前，先查你那个具体版本的发布说明。

确认是哪条关联运走了报文

两个 SA 和两条隧道并不能说明是谁转发了会话。直接问设备，并把字段和你预期的配对对上：

show security ike sa detail
show security ipsec sa detail
show security flow session destination-prefix 10.20.1.0/24
show interfaces st0.1 | match packets

详细输出会给出每条关联的本地与远端网关，这是发现从没预料到的源协商出来的隧道最快的办法。然后在放流量时盯住 st0.1 和 st0.2 的按单元报文计数；什么都没承载的隧道依然会保留 SA，在概览里看着很健康。

给每类故障配自己的探测器

对端存活、本地上行丢失、受保护路由撤销、应用中断是四件不同的事。DPD 只回答第一件，所以要用说得清的间隔和阈值去配置它，而不是留着默认值并假设它覆盖了其余部分：

set security ike gateway GW-A1 dead-peer-detection interval 10
set security ike gateway GW-A1 dead-peer-detection threshold 3
set security ipsec vpn VPN-A1 vpn-monitor source-interface st0.1
set security ipsec vpn VPN-A1 vpn-monitor destination-ip 10.20.0.1

探测远端子网内目的地的隧道监控，覆盖了 DPD 看不到的情况：IKE 还活着，网关也应答，可受保护前缀就是不通。要选好两者里谁去抢优先级，因为同时触发得到的不是切换，而是一场变更风暴。

别忘了远端。留在远端站点上的优选路由仍然指向你已经放弃的隧道，本地定时器修不了这个。把同一套优先级逻辑发布到两端，并记录恢复的链路是可以自动把流量拿回来，还是必须手工切回。

只给一条链路换地址，不碰另一条

运营商给了新地址段时，一次只改一处关系。更新这对地址在两端上的 address 或 local-address，commit，然后只按索引清掉受影响的关联，而不是把设备上所有 SA 全清。全局清理会把健康的那条隧道一起带走，把维护窗口变成故障。

清理之前先留一条失败流量和它的会话明细作为证据，然后对新地址对重跑上面的检查。恢复链路是路由决策，所以要把回切当成独立验证过的一步，而不是假设旧优先级会自己回来。

用一份短清单收尾

双 WAN 隧道设计完成的标准，是你能说出每个会话背后的那一对地址，而不是两个 SA 都起来了。在实际改过的那台设备上过一遍下面的清单：

  • 每个承诺的配对都有网关、st0 单元和路由条目。
  • 每条隧道都被观察到在承载报文，而不只是挂着一个 SA。
  • 两端在检测方式以及由哪一侧恢复优先级上一致。
  • 每个配对的返回路径写在它的去程路径旁边。

哪一行不成立，就先修那一对，再加下一对；叠两条半吊子隧道只会让计数失去意义，让切换行为变得没法预测。

相关文章