IPsec su una WAN privata: limiti di policy sull’SRX da verificare

Una WAN privata può trasportare i pacchetti esterni di un tunnel IPsec, quindi gli indirizzi del peer non devono essere indirizzi internet pubblici. Ciò che cambia è il percorso seguito da quei pacchetti esterni e i permessi sull’interfaccia che li riceve. Su un SRX, il percorso di controllo esterno, il binding dell’interfaccia di tunnel e la policy del traffico inoltrato sono tre oggetti separati. Diagnosticare uno mentre gli altri due sono sbagliati è la ragione abituale per cui un tunnel resta giù.

Registrate prima il percorso IKE esterno

Annotate quattro valori prima di toccare la policy: l’indirizzo del peer, l’interfaccia locale che riceve IKE, il contesto di routing che raggiunge il peer e la rotta che seleziona quell’interfaccia. I pacchetti IKE sono indirizzati allo SRX stesso, quindi richiedono un permesso host-inbound nella zona di ricezione, non una policy del traffico inoltrato. Un indirizzo WAN privato non elimina questo requisito, perché il pacchetto termina comunque sul dispositivo.

Verificate lo stato installato con show security ike sa e la configurazione con show configuration security ike. Il primo indica se esiste la fase 1; la seconda indica ciò che il dispositivo ritiene di dover fare.

Collegate l’interfaccia di tunnel alla policy corretta

Una VPN basata su routing collega un’interfaccia di tunnel a un oggetto VPN, e i prefissi protetti vengono instradati in quell’interfaccia. Annotate quale interfaccia, quale rotta e quale policy consentono le applicazioni tra le zone pertinenti. Una zona chiamata trust è un contenitore di policy, e il nome non dimostra che i pacchetti di controllo o dati necessari siano consentiti.

Leggete i binding reali invece di un vecchio diagramma: show configuration security ipsec vpn per l’impostazione di binding all’interfaccia e show configuration security policies per le regole che fanno riferimento alla zona del tunnel.

Se la rotta protetta punta altrove, il tunnel può essere attivo mentre il traffico non vi entra mai. È un problema di routing travestito da IPsec.

Mantenete la rotta del peer sull’underlay

La rotta verso il peer esterno deve risolversi attraverso l’underlay, non in modo ricorsivo attraverso il tunnel che stabilisce. Se la rotta del peer punta all’interfaccia di tunnel, i pacchetti IKE inseguono il proprio tunnel e la fase 1 non si completa mai. Il percorso di ritorno del traffico protetto richiede la propria rotta e la propria policy corrette, ed è di solito la metà mancante quando una direzione funziona. Leggete la voce della tabella di routing per l’indirizzo del peer e confermate che l’interfaccia in uscita è l’interfaccia WAN.

Verificatelo con show route 198.51.100.10, sostituendo l’indirizzo reale del peer, e confermate che il salto successivo non è un’interfaccia di tunnel.

Verificate controllo e servizio in ordine

Procedete verso l’alto: stato della fase 1, stato della fase 2, poi un flusso applicativo reale. show security ipsec sa elenca le associazioni di sicurezza, e show security flow session destination-prefix 10.60.0.0/16 mostra se vengono create sessioni inoltrate per la rete protetta.

Una relazione di controllo sana e un percorso dati funzionante sono due risultati diversi, e superare la fase 2 non dice nulla sul fatto che la policy consenta l’applicazione. Provate un flusso consentito e uno che la policy dovrebbe rifiutare, così la differenza è visibile.

Annotate insieme la rotta del peer, il permesso host-inbound, il binding del tunnel, la rotta interna e la policy dell’applicazione. Questi cinque record mostrano quale livello possiede un guasto futuro senza affidarsi a un’etichetta di porta.