VPN IPsec dual-WAN în Junos: asocierea căii sursă cu gateway-ul potrivit

Două legături WAN pe sit arată ca redundanță până când încerci să demonstrezi ce pereche de adrese a folosit efectiv un anumit flux. Pe un SRX, un gateway IKE poartă o interfață externă și o adresă locală; o listă de candidați la distanță nu creează o a doua sursă locală. De aceea acest parcurs începe cu matricea perechilor și nu cu configurația, pentru că Junos validează fără probleme un design care acoperă doar jumătate din combinațiile vizate. Am întâlnit asta pe două SRX345s: tunelul de rezervă a urcat curat și totuși a tras sesiunea în jos la revenire.

Parcurge pașii în ordine: enumeră perechile pe care trebuie să le susții, construiește un gateway pentru fiecare sursă locală, confirmă care asociere a dus traficul și abia apoi decide ce poate schimba fiecare tip de defecțiune.

Cartografiază perechile înainte de a atinge CLI-ul

Dacă situl A poate genera trafic din A1 sau A2 și situl B poate primi pe B1 sau B2, ai patru perechi de adrese externe. Majoritatea designurilor au nevoie de două în mod continuu și le tratează pe celelalte două ca opționale. Notează matricea și marchează fiecare rând, pentru că fiecare rând promis te costă mai târziu un gateway, o interfață de tunel și o decizie de rutare.

Fiecare pereche necesară are nevoie de trei lucruri simultan: un underlay accesibil între exact aceste adrese, acceptarea reciprocă a identității partenerului și a adresei sursă la ambele capete, și o cale de întoarcere protejată. O pereche care funcționează doar într-o direcție arată totuși un tunel, iar defecțiunea apare mai târziu ca trafic de aplicație unidirecțional.

Un gateway pe sursă locală, nu pe sit la distanță

Lista adreselor la distanță aparține unui gateway, la fel și sursa locală. referința gateway-urilor IKE ține adresele la distanță, interfața externă, adresa locală și detectarea partenerului mort ca setări separate, și exact aceasta este ideea: două surse locale înseamnă două gateway-uri peste două unități st0. Partajarea politicii IKE între ele este în regulă; păstrarea unui singur gateway și speranța că își schimbă singur sursa nu este.

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

Apoi atașează tunelurile și dă prefixului îndepărtat două next hop-uri, unul pe tunel:

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

Dacă un singur gateway poate ține două instrucțiuni de tipul address depinde de versiune și de procesul IKE pe care rulează echipamentul. Junos mai vechi bazat pe kmd acceptă o singură adresă la distanță pe gateway; build-urile mai noi gestionează mai mulți candidați dar adaugă propriile constrângeri, iar clusterele de înaltă disponibilitate sunt un loc obișnuit unde acel suport se îngustează. Verifică notele de versiune pentru build-ul tău exact înainte de a copia asta de pe un șasiu mai vechi.

Confirmă care asociere a dus pachetul

Două SAs și două tuneluri nu spun care dintre ele a înaintat sesiunea. Întreabă echipamentul direct și compară câmpurile cu perechea pe care o vizai:

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

Ieșirea detaliată indică gateway-ul local și cel la distanță pentru fiecare asociere, ceea ce este cea mai rapidă cale de a observa un tunel negociat dintr-o sursă neașteptată. Apoi urmărește contoarele de pachete pe unitate pe st0.1 și st0.2 în timp ce trimiți trafic; un tunel care nu duce nimic își păstrează SA-ul și pare sănătos într-o vedere de sinteză.

Dă fiecărui tip de defecțiune propriul detector

Vitalitatea partenerului, pierderea legăturii ascendente locale, retragerea rutei protejate și defectarea aplicației sunt patru evenimente diferite. DPD răspunde doar primului, așa că îl configurezi cu un interval și un prag pe care le poți susține în loc să lași valoarea implicită și să presupui că acoperă restul:

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

Monitorizarea tunelului care testează o destinație din subrețeaua îndepărtată acoperă cazul pe care DPD nu îl vede: IKE este viu, gateway-ul răspunde, iar prefixul protejat rămâne inaccesibil. Alege care dintre cele două ar trebui să atragă preferința, pentru că dacă ambele se declanșează simultan apare o furtună de schimbări în loc de un failover curat.

Nu uita capătul îndepărtat. O rută preferată care rămâne instalată pe situl la distanță continuă să indice un tunel pe care l-ai abandonat deja, iar niciun timer local nu repară asta. Publică aceeași logică de preferință pe ambii parteneri și notează dacă o legătură recuperată poate prelua traficul automat sau trebuie comutată manual.

Readresează o legătură fără a o atinge pe cealaltă

Când un ISP îți dă un bloc nou, schimbă o singură relație pe rând. Actualizează address sau local-address pe ambii parteneri pentru acea pereche, fă commit și șterge doar asocierile afectate după index în loc să ștergi toate SAs de pe echipament. O ștergere globală ia și tunelul sănătos și transformă o fereastră de mentenanță într-o cădere.

Păstrează un flux eșuat și detaliul sesiunii sale ca dovadă înainte de a curăța ceva, apoi rulează din nou verificările de mai sus pe noua pereche de adrese. Restabilirea unei legături este o decizie de rutare, așa că tratează revenirea ca un pas testat separat în loc să presupui că vechea preferință revine de la sine.

Închide schimbarea cu o listă scurtă de verificare

Un design de tunel dual-WAN este terminat când poți numi perechea din spatele fiecărei sesiuni, nu când ambele SAs sunt active. Parcurge lista de mai jos pe echipamentul pe care l-ai schimbat efectiv:

• Fiecare pereche promisă are un gateway, o unitate st0 și o intrare de rută.
• Fiecare tunel a fost văzut ducând pachete, nu doar ținând un SA.
• Ambele capete sunt de acord asupra detectării și asupra părții care restabilește preferința.
• Calea de întoarcere pentru fiecare pereche este notată lângă calea de dus.

Dacă o linie eșuează, repară acea pereche înainte de a o adăuga pe următoarea; stivuirea a două tuneluri pe jumătate funcționale face contoarele lipsite de sens și comportamentul de failover imposibil de prezis.