NAT di identità ASA contro l'esclusione NAT IOS per il traffico VPN

Una filiale mantiene PAT internet e una VPN site-to-site sullo stesso gateway Cisco, e la VPN smette di funzionare nel momento in cui si aggiunge NAT. Gli indirizzi dentro il tunnel non corrispondono più a ciò che protegge la crypto ACL, oppure il peer vede indirizzi tradotti per i quali non ha una rotta. Cisco lo risolve in due punti: l'ASA seleziona una regola NAT che mappa un indirizzo su se stesso, mentre IOS tiene il flusso fuori da una regola di traduzione tramite un deny nell'ACL. Entrambi conservano gli indirizzi originali, e nessuno dei due è un aggiramento dell'elaborazione NAT.

Registra il flusso prima di scegliere una regola

Inizia scrivendo il flusso che intendi proteggere: sorgente LAN, destinazione remota e l'esatta coppia di indirizzi protetta dalla politica IPsec. Fallo prima di modificare una regola, perché la tupla indica quale classificatore o regola NAT avrebbe dovuto corrispondere.

Poi trova la regola che ha effettivamente corrisposto, non quella che intendevi. Su entrambe le piattaforme il NAT viene valutato in un ordine, e una regola precedente può vincere prima che la tua eccezione venga esaminata. Un'eccezione che sembra corretta ma perde contro un'altra regola non consegna mai il pacchetto atteso alla politica di protezione. Il sintomo è identico a un'eccezione mancante, per questo l'ordine delle regole va letto prima di cambiare la configurazione.

Il NAT di identità ASA è una regola, non un aggiramento

Sull'ASA, il NAT di identità è una regola NAT la cui traduzione dell'indirizzo è uguale all'originale. Viene selezionata come qualsiasi altra regola e installa comunque una voce di traduzione, quindi il pacchetto non salta l'elaborazione NAT. Ciò che cambia è che gli indirizzi sul filo restano gli stessi, ed è ciò di cui ha bisogno la politica IPsec.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

Le interfacce della regola e la sua impostazione route-lookup devono corrispondere al progetto di inoltro. Una regola che mappa correttamente l'indirizzo ma viene applicata alla coppia di interfacce sbagliata non sarà selezionata per il tuo flusso. Route-lookup decide se il pacchetto tradotto viene instradato o se si usa la destinazione originale, e ciò determina se il traffico di ritorno rientra dal tunnel.

L'accesso di gestione all'ASA stesso è un caso separato. Se usi il NAT di identità per il traffico di gestione, si applica il requisito route-lookup specifico della versione, e un'eccezione ampia copiata da un esempio VPN non riparerà SSH.

Un deny nell'ACL NAT di IOS significa non selezionato qui

Su IOS, il NAT internet è guidato da un elenco di sorgenti, e quell'ACL è un classificatore, non un filtro. Una riga permit seleziona il traffico per la traduzione; una riga deny significa che il pacchetto non è selezionato qui. Quel deny non è un ordine di scartare il pacchetto come lo è un deny in un'ACL di interfaccia.

Non selezionato qui è anche più stretto di mai tradotto da nessuna parte. Un'altra regola NAT, un'altra interfaccia o una route-map possono ancora tradurre il flusso, quindi va letta l'intera tabella NAT. Il pacchetto ha comunque bisogno di una rotta, di una crypto ACL corrispondente e di un permesso ai confini reali del controllo di accesso.

Una disposizione IOS minima mette il deny sopra il permit nello stesso elenco e punta la regola overload a quell'elenco. Allora la crypto ACL protegge la stessa coppia che il deny esclude dalla traduzione.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

Una domanda verificabile per entrambi i modelli

Entrambi i modelli rispondono alla stessa domanda: quale regola ha corrisposto a questo flusso, e quali indirizzi hanno lasciato l'interfaccia? Cattura sull'interfaccia esterna e confronta l'indirizzo di origine prima e dopo il gateway. Poi controlla la visione del peer sul tunnel, perché l'SA può essere attiva mentre il flusso protetto viene tradotto altrove.

Sull'ASA mostra nat detail e la tabella di traduzione; su IOS mostra ip nat translations e i contatori ACL corrispondenti. Una regola che non incrementa mai non è mai stata selezionata, e questo indica l'ordine, l'interfaccia o la direzione più che la configurazione crypto.

Dove la configurazione di solito sbaglia

I guasti comuni sono meccanici. Il deny sta sotto il permit e non corrisponde mai. Il classificatore viene applicato nella direzione sbagliata, quindi il flusso di ritorno viene tradotto. La regola di identità copre gli indirizzi giusti ma la coppia di interfacce sbagliata. La crypto ACL protegge una sottorete che non corrisponde più a ciò che presenta la regola NAT.

Registra la coppia di indirizzi originale e presentata accanto al proprietario della regola, così il prossimo ingegnere vede perché un classificatore nega la traduzione mentre il firewall consente l'applicazione. Conservalo nel ticket di modifica, non in una nota personale. Poi riesegui il flusso dopo ogni modifica NAT, perché l'ordine delle regole fa parte della configurazione anche quando il testo della regola è invariato. Un tunnel che sale non prova che gli indirizzi siano sopravvissuti; solo il pacchetto catturato e la vista decapsulata del peer lo provano.