VPN IPsec double WAN sur Junos : associer le chemin source à la bonne passerelle

Deux liens WAN par site ressemblent à de la redondance tant qu’on ne cherche pas à prouver quelle paire d’adresses un flux donné a réellement utilisée. Sur un SRX, une passerelle IKE porte une interface externe et une adresse locale ; une liste de candidats distants ne crée pas une seconde source locale. C’est pourquoi ce parcours commence par la matrice des paires et non par la configuration, car Junos valide volontiers une conception qui ne couvre que la moitié des combinaisons prévues. Je l’ai rencontré sur deux SRX345s : le tunnel de secours montait proprement et faisait quand même chuter la session au retour.

Suivez les étapes dans l’ordre : énumérez les paires à prendre en charge, construisez une passerelle par source locale, confirmez quelle association a porté le trafic, et décidez seulement ensuite ce que chaque type de panne peut changer.

Cartographier les paires avant de toucher à la CLI

Si le site A peut émettre depuis A1 ou A2 et que le site B peut recevoir sur B1 ou B2, vous avez quatre paires d’adresses externes. La plupart des conceptions en ont besoin de deux en permanence et traitent les deux autres comme optionnelles. Notez la matrice et marquez chaque ligne, car chaque ligne promise coûte plus tard une passerelle, une interface tunnel et une décision de routage.

Chaque paire requise a besoin de trois choses à la fois : un underlay joignable entre ces adresses précises, l’acceptation mutuelle de l’identité du pair et de l’adresse source aux deux extrémités, et un chemin de retour protégé. Une paire qui ne fonctionne que dans un sens affiche quand même un tunnel, et la panne se révèle plus tard sous forme de trafic applicatif à sens unique.

Une passerelle par source locale, pas par site distant

La liste des adresses distantes appartient à une passerelle, et la source locale aussi. La référence des passerelles IKE conserve les adresses distantes, l’interface externe, l’adresse locale et la détection de pair mort comme des réglages distincts, et c’est tout l’intérêt : deux sources locales signifient deux passerelles sur deux unités st0. Partager la politique IKE entre elles est acceptable ; garder une seule passerelle en espérant qu’elle change elle-même de source ne l’est pas.

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

Rattachez ensuite les tunnels et donnez au préfixe distant deux sauts suivants, un par tunnel :

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

Qu’une seule passerelle puisse porter deux instructions de type address dépend de la version et du processus IKE exécuté par la machine. Les Junos plus anciens à base de kmd n’acceptent qu’une seule adresse distante par passerelle ; les versions récentes gèrent plusieurs candidats mais ajoutent leurs propres contraintes, et les clusters de haute disponibilité sont un endroit courant où ce support se réduit. Consultez les notes de version de votre build exact avant de copier ceci depuis un châssis plus ancien.

Confirmer quelle association a porté le paquet

Deux SAs et deux tunnels ne disent pas lequel a fait suivre la session. Interrogez la machine directement et comparez les champs à la paire que vous visiez :

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

La sortie détaillée indique la passerelle locale et la passerelle distante de chaque association, ce qui est le moyen le plus rapide de repérer un tunnel négocié depuis une source inattendue. Surveillez ensuite les compteurs de paquets par unité sur st0.1 et st0.2 pendant que vous poussez du trafic ; un tunnel qui ne transporte rien conserve sa SA et paraît sain dans une vue de synthèse.

Donner à chaque panne son propre détecteur

La vivacité du pair, la perte du lien montant local, le retrait de la route protégée et la casse applicative sont quatre événements différents. DPD ne répond que du premier, alors configurez-le avec un intervalle et un seuil que vous pouvez justifier au lieu de laisser la valeur par défaut et de supposer qu’elle couvre le reste :

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

Une supervision de tunnel qui sonde une destination à l’intérieur du sous-réseau distant couvre le cas que DPD ne voit pas : IKE est vivant, la passerelle répond, et le préfixe protégé est injoignable malgré tout. Choisissez lequel des deux doit tirer la préférence, car si les deux se déclenchent en même temps, vous obtenez une tempête de changements plutôt qu’un basculement propre.

N’oubliez pas l’extrémité distante. Une route préférée qui reste installée sur le site distant continue de pointer vers un tunnel que vous avez déjà abandonné, et aucune minuterie locale ne corrige cela. Publiez la même logique de préférence sur les deux pairs, et notez si un lien rétabli peut reprendre le trafic automatiquement ou doit être basculé à la main.

Réadresser un lien sans toucher l’autre

Quand un FAI vous attribue un nouveau bloc, changez une relation à la fois. Mettez à jour address ou local-address sur les deux pairs pour cette paire, validez, et effacez uniquement les associations concernées par index au lieu d’effacer toutes les SAs de la machine. Un effacement global emporte aussi le tunnel sain et transforme une fenêtre de maintenance en panne.

Conservez un flux en échec et le détail de sa session comme preuve avant de nettoyer quoi que ce soit, puis relancez les vérifications ci-dessus sur la nouvelle paire d’adresses. Rétablir un lien est une décision de routage, traitez donc le retour comme une étape testée à part entière au lieu de supposer que l’ancienne préférence revient d’elle-même.

Clôturer le changement par une courte liste de contrôle

Une conception de tunnel double WAN est terminée quand vous pouvez nommer la paire derrière chaque session, pas quand les deux SAs sont montées. Parcourez la liste ci-dessous sur la machine que vous avez réellement modifiée :

• Chaque paire promise dispose d’une passerelle, d’une unité st0 et d’une entrée de route.
• Chaque tunnel a été vu transportant des paquets, pas seulement conservant une SA.
• Les deux extrémités s’accordent sur la détection et sur le côté qui rétablit la préférence.
• Le chemin de retour de chaque paire est noté à côté de son chemin aller.

Si une ligne échoue, corrigez cette paire avant d’ajouter la suivante ; empiler deux tunnels à moitié fonctionnels rend les compteurs inutiles et le comportement de basculement imprévisible.