VPN IPsec dual WAN su Junos: associare il percorso sorgente al gateway giusto

Due link WAN per sito sembrano ridondanza finché non si prova a dimostrare quale coppia di indirizzi un dato flusso ha realmente usato. Su un SRX un gateway IKE porta un’interfaccia esterna e un indirizzo locale; un elenco di candidati remoti non crea una seconda sorgente locale. Per questo la guida parte dalla matrice delle coppie e non dalla configurazione, perché Junos committa volentieri un progetto che copre solo metà delle combinazioni previste. Mi è capitato su due SRX345s: il tunnel di backup saliva pulito e faceva comunque cadere la sessione al rientro.

Segui i passi in ordine: elenca le coppie da supportare, costruisci un gateway per ogni sorgente locale, conferma quale associazione ha trasportato il traffico e solo dopo decidi cosa ogni tipo di guasto può cambiare.

Mappare le coppie prima di toccare la CLI

Se il sito A può generare traffico da A1 o A2 e il sito B può ricevere su B1 o B2, hai quattro coppie di indirizzi esterni. La maggior parte dei progetti ne ha bisogno di due in modo continuo e tratta le altre due come opzionali. Annota la matrice e contrassegna ogni riga, perché ogni riga promessa costa poi un gateway, un’interfaccia tunnel e una decisione di routing.

Ogni coppia richiesta ha bisogno di tre cose insieme: un underlay raggiungibile tra quegli indirizzi esatti, l’accettazione reciproca dell’identità del peer e dell’indirizzo sorgente a entrambi i capi, e un percorso di ritorno protetto. Una coppia che funziona solo in una direzione mostra comunque un tunnel, e il guasto emerge più tardi come traffico applicativo a senso unico.

Un gateway per sorgente locale, non per sito remoto

L’elenco degli indirizzi remoti appartiene a un gateway, e così la sorgente locale. La documentazione dei gateway IKE tiene indirizzi remoti, interfaccia esterna, indirizzo locale e rilevamento del peer morto come impostazioni separate, ed è proprio il punto: due sorgenti locali significano due gateway su due unità st0. Condividere la policy IKE tra loro va bene; tenere un solo gateway sperando che cambi sorgente da sé, 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-only

Collega poi i tunnel e assegna al prefisso remoto due next hop, uno per 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

Se un solo gateway possa mantenere due istruzioni di tipo address dipende dalla release e dal processo IKE in esecuzione sulla macchina. I Junos più vecchi basati su kmd accettano un solo indirizzo remoto per gateway; le build più recenti gestiscono più candidati ma aggiungono vincoli propri, e i cluster ad alta disponibilità sono un punto comune in cui quel supporto si restringe. Controlla le note di rilascio della tua build esatta prima di copiare questo da un chassis più vecchio.

Confermare quale associazione ha trasportato il pacchetto

Due SA e due tunnel non dicono quale dei due ha inoltrato la sessione. Interroga direttamente la macchina e confronta i campi con la coppia che intendevi:

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

L’output di dettaglio riporta il gateway locale e quello remoto per ogni associazione, ed è il modo più rapido per individuare un tunnel negoziato da una sorgente che non ti aspettavi. Poi osserva i contatori di pacchetti per unità su st0.1 e st0.2 mentre spingi traffico; un tunnel che non trasporta nulla conserva la sua SA e sembra sano in una vista di riepilogo.

Dare a ogni guasto il proprio rilevatore

Vitalità del peer, perdita del collegamento in salita locale, ritiro della rotta protetta e rottura applicativa sono quattro eventi diversi. DPD risponde solo al primo, quindi configuralo con un intervallo e una soglia che sai difendere invece di lasciare il valore predefinito e dare per scontato che copra il 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.1

Un monitoraggio del tunnel che sonda una destinazione dentro la sottorete remota copre il caso che DPD non vede: IKE è vivo, il gateway risponde e il prefisso protetto resta irraggiungibile. Scegli quale dei due deve attirare la preferenza, perché se scattano entrambi insieme ottieni una tempesta di cambi invece di un failover pulito.

Non dimenticare il capo remoto. Una rotta preferita che resta installata sul sito remoto continua a puntare in un tunnel che hai già abbandonato, e nessun timer locale lo corregge. Pubblica la stessa logica di preferenza su entrambi i peer e annota se un collegamento ripristinato possa riprendersi il traffico da solo o debba essere commutato a mano.

Ri-indirizzare un collegamento senza toccare l’altro

Quando un ISP ti assegna un nuovo blocco, cambia una relazione alla volta. Aggiorna address o local-address su entrambi i peer per quella coppia, committa ed elimina solo le associazioni interessate per indice invece di cancellare tutte le SA della macchina. Una cancellazione globale porta via anche il tunnel sano e trasforma una finestra di manutenzione in un’interruzione.

Conserva un flusso fallito e il dettaglio della sua sessione come prova prima di fare pulizia, poi ripeti i controlli qui sopra sulla nuova coppia di indirizzi. Ripristinare un collegamento è una decisione di routing, quindi tratta il ritorno come un passo testato a sé invece di dare per scontato che la vecchia preferenza torni da sola.

Chiudere la modifica con una breve lista di controllo

Un progetto di tunnel dual WAN è finito quando sai nominare la coppia dietro ogni sessione, non quando le due SA sono attive. Percorri la lista qui sotto sulla macchina che hai davvero modificato:

• Ogni coppia promessa ha un gateway, un’unità st0 e una voce di rotta.
• Ogni tunnel è stato visto trasportare pacchetti, non solo mantenere una SA.
• Entrambi i capi concordano sul rilevamento e su quale lato ripristina la preferenza.
• Il percorso di ritorno di ogni coppia è annotato accanto al suo percorso di andata.

Se una riga non regge, sistema quella coppia prima di aggiungere la successiva; impilare due tunnel a metà rende i contatori privi di senso e il comportamento di failover imprevedibile.