FortiGate dietro NAT: local-gw, localid e l'IP pubblico

Un FortiGate dietro NAT può possedere 10.0.0.2 sulla sua interfaccia WAN mentre internet lo presenta come 198.51.100.40, ed entrambi i numeri sono reali. L'indirizzo a cui il dispositivo si lega e l'identità che invia durante l'autenticazione IKE sono scelte separate, fatte in campi separati, per pubblici separati. NAT riscrive l'indirizzamento esterno al passaggio; non riscrive un'identità autenticata in ciò che il peer remoto si aspetta. La maggior parte dei guasti di fase 1 in questa forma deriva dal mettere il valore giusto nel campo sbagliato.

Tre valori, tre proprietari

Iniziate nominando i tre valori e chi possiede ciascuno. local-gw è l'indirizzo che il FortiGate usa come origine per IKE sulla sua interfaccia esterna, e deve essere un indirizzo che il dispositivo possiede davvero. L'endpoint pubblico è l'indirizzo del dispositivo NAT, posseduto da chi esegue la traduzione. L'identità IKE è una stringa che il peer confronta con la propria configurazione, e non deve affatto essere un indirizzo IP.

I nomi dei campi sono abbastanza simili da invitare alla sostituzione, e questa è la trappola. localid e localid-type descrivono l'identificazione; local-gw descrive il legame locale.

Un esempio rende concreta la distinzione. Sul FortiGate, aprite config vpn ipsec phase1-interface, poi set interface "wan1" e set local-gw 10.0.0.2 — un indirizzo che il dispositivo possiede, ed è ciò che fa legare correttamente il socket IKE. Lasciate local-gw su 0.0.0.0 e viene usato l'indirizzo dell'interfaccia, che di solito è la stessa cosa ma meno esplicito. Non impostate local-gw su 198.51.100.40, perché il dispositivo non possiede quell'indirizzo e il socket non vi si legherà. Far sembrare uguali due valori sulla carta non è una configurazione.

Passo 1: scegliete l'identità che il peer accetterà

Ora l'identità, che è una decisione diversa. set localid prende il valore che il peer confronterà, e set localid-type dice al FortiGate come interpretarlo: un indirizzo, un FQDN, un FQDN utente o un ID chiave. Con auto il dispositivo lo deriva, di solito dall'indirizzo dell'interfaccia in uscita, che è esattamente il valore che un dispositivo NAT sta per cambiare.

Questa derivazione è il motivo per cui un'identità esplicita conta in questa topologia. Se il peer si aspetta un'identità di indirizzo, impostate localid-type address e localid sull'indirizzo pubblico che il peer vedrà, poi confermate che il peer accetta quel valore come identità e non come destinazione di instradamento. Se il peer si aspetta un FQDN, usate localid-type fqdn e il nome con cui è stato configurato. Verificate ciò che è stato realmente inviato con diagnose vpn ike gateway list, che mostra lo stato del gateway e gli identificatori in uso, non ciò che intendevate digitare. Non date per scontato che un'opzione di tipo identità accetti un indirizzo non locale arbitrario; controllate prima la semantica documentata della versione.

Passo 2: inoltrate UDP 500 e 4500 al dispositivo

Il terzo valore appartiene al dispositivo NAT, ed è quello che la gente dimentica di controllare. L'endpoint pubblico deve inoltrare UDP 500 e UDP 4500 al FortiGate, perché il rilevamento NAT-T e l'ESP incapsulato che segue dipendono entrambi dall'arrivo di quelle porte. Questo progetto presuppone una mappatura uno a uno; condividere un solo indirizzo pubblico tramite porte tra più peer è un'altra topologia con altri limiti.

Confermate l'inoltro con una cattura e non con una speranza: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 mostra se i pacchetti arrivano e se le risposte partono.

Google Cloud VPN documenta NAT uno a uno con NAT-T come disposizione supportata per un peer dietro NAT, e questo è il vincolo con cui progettare se l'estremità remota è un gateway Cloud VPN. La condivisione uno a molti o tramite porte non è la stessa topologia supportata, e nessuna regolazione locale dell'identità lo cambia. Se il lato remoto è un altro apparato, la sua documentazione definisce cosa accetterà come identità e se tollera un indirizzo peer tradotto. Leggetela prima di cambiare un campo locale, perché il lato locale non può negoziare una regola che il lato remoto non implementa.

Passo 3: verificate ciò che la fase 1 non risolve

La traversata NAT alza il tunnel, l'accordo sull'identità decide se il peer lo accetta, e l'instradamento del prefisso interno decide cosa passa davvero. Un ID locale corretto non può fornire una rotta statica mancante né un selettore di traffico mancante.

Quindi verificate a strati. get vpn ipsec tunnel details mostra se il tunnel è attivo e quali selettori sono stati negoziati, e una discrepanza tra la sottorete remota configurata e il selettore negoziato è un problema di instradamento in costume di fase 2. execute vpn ike gateway clear forza una rinegoziazione, quindi state testando la configurazione attuale e non una sessione stabilita prima della vostra ultima modifica. Poi inviate traffico verso un host nel prefisso remoto e confermate che i contatori si muovono, perché un tunnel attivo che non passa nulla è identico a uno funzionante finché non controllate.

Tenete i tre valori in un solo posto nei vostri appunti: l'indirizzo locale che il dispositivo possiede, l'endpoint pubblico che il dispositivo NAT presenta e la stringa di identità che il peer si aspetta. Cambiano per motivi diversi e in momenti diversi.

Una rinumerazione del dispositivo NAT non è un motivo per toccare local-gw del FortiGate, e un cambio di identità non è un motivo per rinumerare nulla. Mescolare le due cose è il modo in cui un tunnel funzionante viene ricostruito durante una finestra di manutenzione non correlata. La guida NAT di Cloud VPN è il riferimento per la topologia supportata su quel lato.

Il test che risolve la questione è noioso e veloce: catturate sull'interfaccia esterna, confermate che UDP 500 e 4500 arrivino dal peer, confermate che l'identità nello scambio IKE corrisponda a ciò che il peer era configurato per aspettarsi, poi confermate che i selettori negoziati coprano le sottoreti che vi interessano. Se il primo controllo fallisce, il sospetto è il dispositivo NAT. Se fallisce il secondo, sono i campi di identità. Se fallisce il terzo, né NAT né identità sono mai stati il problema.