VPN IPsec de doble WAN en Junos: emparejar la ruta de origen con la pasarela
Un recorrido por SRX con Junos para IPsec de doble WAN: empareja cada origen local con sus pasarelas candidatas y luego demuestra qué asociación transportó realmente el tráfico.
Dos enlaces WAN por sitio parecen redundancia hasta que intentas demostrar qué par de direcciones utilizó realmente un flujo concreto. En un SRX, una pasarela IKE transporta una interfaz externa y una dirección local; una lista de candidatos remotos no crea un segundo origen local. Por eso este recorrido empieza por la matriz de pares y no por la configuración, porque Junos valida sin problema un diseño que solo cubre la mitad de las combinaciones previstas. Me pasó con dos SRX345s: el túnel de respaldo subió limpio y aun así arrastró la sesión en la vuelta atrás.
Recorre los pasos en orden: enumera los pares que debes soportar, construye una pasarela por origen local, confirma qué asociación transportó el tráfico y solo entonces decide qué puede cambiar cada tipo de fallo.
Dibujar los pares antes de tocar la CLI
Si el sitio A puede originar desde A1 o A2 y el sitio B puede recibir en B1 o B2, tienes cuatro pares de direcciones externas. La mayoría de los diseños necesitan dos de forma continua y tratan los otros dos como opcionales. Anota la matriz y marca cada fila, porque cada fila prometida te cuesta después una pasarela, una interfaz de túnel y una decisión de enrutamiento.
| Local source | Remote candidate | Required? |
|---|---|---|
| A1, ISP1 address | B1 | steady state |
| A1, ISP1 address | B2 | decide explicitly |
| A2, ISP2 address | B1 | decide explicitly |
| A2, ISP2 address | B2 | backup path |
Cada par necesario requiere tres cosas a la vez: un underlay alcanzable entre esas direcciones exactas, aceptación mutua de la identidad del par y de la dirección de origen en ambos extremos, y una ruta de retorno protegida. Un par que solo funciona en un sentido sigue mostrando un túnel, y el fallo aparece más tarde como tráfico de aplicación unidireccional.
Una pasarela por origen local, no por sitio remoto
La lista de direcciones remotas pertenece a una pasarela, y el origen local también. La referencia de pasarelas IKE mantiene las direcciones remotas, la interfaz externa, la dirección local y la detección de par muerto como ajustes separados, y de eso se trata: dos orígenes locales significan dos pasarelas sobre dos unidades st0. Compartir la política IKE entre ellas está bien; quedarse con una sola pasarela y esperar que cambie de origen sola, no.
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-onlyDespués conecta los túneles y da al prefijo remoto dos next hops, uno por túnel:
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 20Que una pasarela pueda mantener dos instrucciones de tipo address depende de la versión y de qué proceso IKE ejecute el equipo. Los Junos antiguos basados en kmd aceptan una sola dirección remota por pasarela; las compilaciones nuevas manejan varios candidatos pero añaden sus propias restricciones, y los clústeres de alta disponibilidad son un lugar habitual donde ese soporte se estrecha. Consulta las notas de versión de tu compilación exacta antes de copiar esto desde un chasis más antiguo.
Confirmar qué asociación transportó el paquete
Dos SAs y dos túneles no dicen cuál de ellos reenvió la sesión. Pregunta al equipo directamente y compara los campos con el par que pretendías:
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 packetsLa salida detallada indica la pasarela local y la remota de cada asociación, que es la forma más rápida de detectar un túnel negociado desde un origen que no esperabas. Luego observa los contadores de paquetes por unidad en st0.1 y st0.2 mientras envías tráfico; un túnel que no transporta nada conserva su SA y parece sano en una vista resumida.
Dar a cada fallo su propio detector
La vitalidad del par, la pérdida del enlace ascendente local, la retirada de la ruta protegida y la rotura de la aplicación son cuatro eventos distintos. DPD solo responde al primero, así que configúralo con un intervalo y un umbral que puedas defender en lugar de dejar el valor por defecto y suponer que cubre el resto:
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.1La supervisión de túnel que sondea un destino dentro de la subred remota cubre el caso que DPD no ve: IKE está vivo, la pasarela responde y el prefijo protegido sigue siendo inalcanzable. Elige cuál de los dos debe atraer la preferencia, porque si ambos se disparan a la vez se produce una tormenta de cambios en lugar de un failover limpio.
No olvides el extremo remoto. Una ruta preferida que permanece instalada en el sitio remoto sigue apuntando a un túnel que ya abandonaste, y ningún temporizador local lo arregla. Publica la misma lógica de preferencia en ambos pares y anota si un enlace recuperado puede recuperar el tráfico automáticamente o debe conmutarse a mano.
Readresar un enlace sin tocar el otro
Cuando un ISP te entrega un bloque nuevo, cambia una relación cada vez. Actualiza address o local-address en ambos pares para ese par, confirma, y borra solo las asociaciones afectadas por índice en lugar de borrar todas las SAs del equipo. Un borrado global se lleva también el túnel sano y convierte una ventana de mantenimiento en una caída.
Guarda un flujo fallido y el detalle de su sesión como prueba antes de limpiar nada, y luego repite las comprobaciones anteriores contra el nuevo par de direcciones. Restaurar un enlace es una decisión de enrutamiento, así que trata la vuelta como un paso probado por sí mismo en lugar de suponer que la preferencia antigua regresa sola.
Cerrar el cambio con una lista corta
Un diseño de túnel de doble WAN está terminado cuando puedes nombrar el par detrás de cada sesión, no cuando ambas SAs están levantadas. Recorre la lista siguiente en el equipo que realmente cambiaste:
- Cada par prometido tiene una pasarela, una unidad st0 y una entrada de ruta.
- Cada túnel se ha visto transportando paquetes, no solo manteniendo una SA.
- Ambos extremos coinciden en la detección y en qué lado restaura la preferencia.
- La ruta de retorno de cada par está anotada junto a su ruta de ida.
Si una línea falla, arregla ese par antes de añadir el siguiente; apilar dos túneles a medias hace que los contadores no signifiquen nada y que el failover sea impredecible.