Quale interfaccia riceve il ruolo NAT interno ed esterno su un'uscita VPN IOS

I router che offrono un'uscita Internet a tunnel completo svolgono due compiti che sembrano uno. Terminano il tunnel e inoltrano il pacchetto client decifrato verso Internet. Solo il secondo compito richiede una traduzione, e la traduzione deve corrispondere al flusso interno. Questa distinzione decide quali interfacce portano i ruoli NAT e quale intervallo di indirizzi compare nella regola.

Seguite un pacchetto attraverso il router

Prendete un client su 10.90.0.25 che apre un servizio HTTPS pubblico. Se quella destinazione entri o meno nel tunnel è una decisione della politica del client stesso. Una volta che entra, il router decifra il pacchetto e lo consegna a un'interfaccia virtuale, da dove viene instradato verso il collegamento in salita pubblico.

Quell'interfaccia virtuale è il lato interno della traduzione. Il collegamento in salita pubblico è il lato esterno. Se i ruoli sono invertiti o mancano, il pacchetto esce con una sorgente privata oppure viene scartato prima di essere tradotto.

Adattate la politica di traduzione al pool di client

La regola NAT deve nominare l'intervallo che i client ricevono davvero, non la LAN dell'ufficio che per caso condivide lo stesso collegamento in salita. Una regola che copre solo la sottorete locale manca i client remoti anche quando entrambi escono dalla stessa interfaccia.

ip access-list extended NAT-TUNNEL
 permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overload

Tenete separate le eccezioni per i siti privati. Il traffico verso destinazioni interne deve conservare la sorgente originale, altrimenti la destinazione risponderà a un indirizzo che non può raggiungere e il tratto di ritorno fallirà in un modo che sembra un loop di instradamento.

Applicate i ruoli alle interfacce reali nel progetto distribuito. Un frammento Virtual-Template copiato da una vecchia risposta Easy VPN non è una configurazione attuale completa, e il tipo di tunnel usato determina quale interfaccia riceve il pacchetto decifrato.

Separate il trasporto esterno dalla traduzione interna

Tradurre una sorgente applicativa decifrata non è la stessa operazione del spingere pacchetti IKE o protetti attraverso un dispositivo NAT più a monte. La prima cambia ciò che Internet vede come sorgente della richiesta del client; la seconda mantiene vivo un tunnel attraverso un elemento intermedio.

Confonderle produce due guasti classici. Un router che traduce il proprio trasporto di tunnel rompe il rapporto con il peer, mentre un router che non traduce mai il flusso interno inoltra indirizzi privati su Internet. Leggete quale flusso state guardando prima di modificare una regola, e verificate se il tunnel è rimasto attivo dopo la modifica. Una regola che sistema la navigazione ma fa cadere il tunnel ha spostato il problema invece di risolverlo.

Nessuno dei due guasti si corregge cambiando l'altro. Leggete quale flusso state guardando prima di modificare una regola.

Verificate a entrambi i confini

Leggete la sorgente dell'applicazione al confine di Internet, e la destinazione ripristinata sul tratto di ritorno. La prima dice se la traduzione è avvenuta; la seconda dice se la mappatura inversa è tornata al client giusto.

Poi provate un client che usa un percorso di tunnel diviso approvato. Quel client non esercita mai la traduzione Internet di questo router, quindi dovrebbe comportarsi diversamente, e la differenza conferma quale percorso ha preso il traffico.

Se entrambi i client si comportano allo stesso modo, la politica di tunnel diviso non fa ciò che dice il progetto. Correggetelo prima di aggiungere altre regole di traduzione, perché una regola scritta per un percorso non usato nasconde il problema reale.