ASA hairpin: uscita internet o gamba VPN site-to-site?

Due utenti di accesso remoto dietro lo stesso ASA possono inviare traffico dalla stessa interfaccia esterna e ricevere un trattamento completamente diverso. Uno va verso un sito web pubblico, quindi il pacchetto ha bisogno della traduzione di origine e di una rotta internet. L’altro va verso un server dietro un tunnel site-to-site che termina anch’esso su quell’interfaccia, quindi il pacchetto ha bisogno di identità, di un selettore di tunnel corrispondente e di un percorso di ritorno verso il pool client. Il permesso per la stessa interfaccia è un prerequisito per entrambi e una soluzione per nessuno.

Due gambe, un’interfaccia

Decidete quale gamba state costruendo prima di digitare una regola NAT, perché le regole non sono intercambiabili. La gamba A è da client a internet: indirizzo del pool in ingresso, indirizzo pubblico tradotto in uscita, ritorno attraverso la stessa interfaccia. La gamba B è da client a un prefisso privato dall’altra parte di un altro peer IPsec: l’indirizzo del pool viene conservato, ricifrato e consegnato a un peer che deve sapere come rispondere al pool.

Ciò di cui entrambe hanno bisogno per prima cosa è il permesso per la stessa interfaccia. Senza di esso l’ASA rifiuta di inoltrare un pacchetto dall’interfaccia da cui è arrivato, e il guasto sembra un problema di routing invece che di policy:

same-security-traffic permit intra-interface

Quella singola riga autorizza una disposizione di inoltro, come descrive il riferimento NAT di ASA per i percorsi sulla stessa interfaccia. Non aggiunge una rotta client, non autorizza una risorsa, non traduce un indirizzo né negozia un selettore IPsec, quindi aspettatevi di aggiungere altre tre o quattro cose dopo e non leggete la sua accettazione come un progresso.

Gamba A: il client vuole internet

Per un’uscita internet l’indirizzo del pool deve smettere di essere privato prima che il pacchetto lasci il dispositivo. In un progetto PAT ordinario la regola traduce il pool nell’indirizzo dell’interfaccia esterna, e lo stato di ritorno ripristina il flusso verso il client:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

Poi confermate che il client abbia davvero chiesto all’ASA di trasportare quel traffico. Un’esclusione dal tunnel diviso invia la destinazione pubblica sulla connessione propria del telefono, che non raggiunge mai l’ASA, e nessuna regola NAT ripara un pacchetto che non è mai stato inviato. Confrontate la lista del tunnel diviso della politica di gruppo con la destinazione che state testando.

Il resto della gamba è ordinario: una rotta predefinita o specifica utilizzabile dall’interfaccia esterna, una politica di accesso che consente il flusso e DNS gestito secondo la politica di resolver scelta. Aggiungete route-lookup qui per lo stesso motivo di sotto, dato che l’interfaccia di ingresso e quella di uscita sono identiche.

Gamba B: il client vuole un sito privato

Questa gamba fallisce in più punti, quindi scrivetela in ordine. Prima la rotta client: il prefisso di destinazione deve essere nella lista del tunnel diviso, altrimenti il client non lo metterà nel tunnel. Poi il selettore di tunnel: l’ACL crittografica site-to-site deve coprire dall’indirizzo del pool al prefisso remoto, non solo dalla LAN locale al prefisso remoto. Infine l’identità, così che l’indirizzo del pool non venga tradotto nel PAT internet al passaggio.

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

Il lato remoto è la parte che la gente dimentica di testare. Il peer ha bisogno di una rotta di ritorno verso il pool e di un selettore che lo includa, e la sua politica deve consentire gli indirizzi di origine che vedrà. Se il sito viene usato invece tramite una vista tradotta, è un progetto valido, ma allora entrambi i peer, entrambi i selettori e entrambe le tabelle di routing devono concordare sugli indirizzi tradotti.

Controllate anche l’ordine delle regole. Una regola PAT ampia sopra la regola di identità tradurrà lo scambio privato prima che la regola di identità venga valutata, e il sintomo è un tunnel di sito senza SA corrispondente invece di un errore NAT.

Il test che vi dice quale gamba avete costruito

Usate la valutazione del percorso dell’ASA stesso invece di leggere la configurazione e sperare. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed mostra la decisione NAT, la rotta e il risultato ACL per un flusso; ripetetelo con una destinazione privata. Se la fase NAT riscrive un flusso da privato a privato, avete costruito la gamba A per un pacchetto che aveva bisogno della gamba B.

Altri due comandi chiudono il divario. show nat detail stampa l’ordine delle regole seguito da packet-tracer, e show crypto ipsec sa mostra se esiste un selettore per la coppia che vi aspettate. Un SA mancante è una questione di configurazione del selettore o del peer, non qualcosa che la regola NAT possa riparare.

Verificate ogni gamba con il traffico che serve

Accettate la gamba A con una richiesta pubblica ordinaria dal client, e la gamba B con una richiesta a una risorsa privata che esista davvero. Poi ripetete ciascuna con una risorsa negata, perché «consentito» e «approvato dalla politica di accesso» non sono la stessa prova, e un ping originato dall’hub non esercita nessuno dei due percorsi client.

Tenete i due record di test separati nel ticket: indirizzo di origine, destinazione, regola NAT che ha corrisposto e risultato. Quando il prossimo rapporto dirà «la VPN è rotta», quella coppia vi dice in un minuto quale gamba ha regredito, e la risposta di solito è una rotta o un selettore invece della riga della stessa interfaccia che tutti sospettano per prima.