ASA VPN hairpin: instradare due tunnel attraverso una sola interfaccia

Un utente remoto si connette all'ASA, chiede un host dietro una filiale, e l'ASA invia quella richiesta proprio dall'interfaccia da cui è arrivato l'utente. Nulla di tutto ciò richiede una seconda porta fisica. Ciò che richiede sono quattro decisioni indipendenti che le persone tendono a fondere in una: il permesso di fare hairpin, un tunnel che protegga gli indirizzi giusti, una politica NAT che conservi l'origine che hai promesso e una politica di accesso che autorizzi il servizio.

Un pacchetto, due tunnel

Segui il flusso e l'ordine delle operazioni smette di essere misterioso. Il pacchetto arriva dentro il tunnel di accesso remoto, viene decifrato e diventa un normale pacchetto IP con origine dal pool di client. L'ASA lo instrada, lo confronta con l'ACL di crittografia da sito a sito, lo cifra di nuovo e lo invia dall'interfaccia esterna verso la filiale.

Gli indirizzi seguenti sono illustrativi, ma la forma conta: l'origine è il pool, non la LAN interna dell'ASA.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

Ne derivano due cose. Il client ha bisogno di una rotta per il prefisso della filiale attraverso la sua connessione di accesso remoto, il che significa che lo split-tunnel o la lista di rotte inviata deve includerla. E la filiale deve sapere come restituire il traffico a 10.77.0.20 o all'indirizzo che il tuo progetto NAT ha sostituito.

L'autorizzazione hairpin è globale

Il comando a cui le persone ricorrono è same-security-traffic permit intra-interface. Consente al traffico di entrare e uscire dalla stessa interfaccia, che è esattamente ciò di cui ha bisogno questo percorso. È anche un'impostazione globale: abilitarla cambia il comportamento di altri flussi che attraversano accidentalmente due volte la stessa interfaccia.

Ecco perché appartiene a un registro delle modifiche e non a una sessione di debug. Chiediti cos'altro sull'apparecchio potrebbe ora prendere un percorso attraverso la stessa interfaccia, e se qualcosa dovrebbe. Su un bordo trafficato con reti ospiti o tunnel di partner sovrapposti, la risposta non è automaticamente no. Scrivi il motivo accanto all'impostazione, perché il prossimo ingegnere troverà il comando e non la conversazione.

Portata della protezione e NAT sono separati

Il tunnel da sito a sito protegge ciò che seleziona la sua ACL di crittografia. Se quell'ACL indica la sottorete interna dell'ASA come origine, il pool di accesso remoto non è protetto e il pacchetto verrà scartato o inviato in chiaro, a seconda del comportamento della piattaforma per il traffico non corrispondente. Aggiungi il pool al flusso protetto quando il progetto conserva gli indirizzi del pool.

Poi il NAT decide se l'indirizzo del pool sopravvive. L'Identity NAT lo conserva, e la filiale vede 10.77.0.20 come origine. La traduzione cambia il contratto: la filiale ora restituisce il traffico all'indirizzo tradotto, e la sua politica deve accettarlo. L'ordine delle regole decide se l'ACL di crittografia corrisponde prima o dopo la traduzione, quindi leggi il flusso effettivo invece di presumere quale vince.

Non eliminare le regole PAT generali di internet per far funzionare un solo caso di transito. Un'esenzione mirata o una regola di identità deliberata sono più facili da spiegare e da annullare di un buco nella politica in uscita.

La crittografia non è autorizzazione

Un tunnel funzionante dimostra solo che due peer concordano su chiavi e selettori. Non dice nulla sulla possibilità che questo utente raggiunga quel servizio. Il filtro VPN o la politica di gruppo collegati alla connessione di accesso remoto devono ancora consentire la destinazione e la porta della filiale, e l'ACL dell'interfaccia sul percorso esterno si applica ancora.

Prova la risposta in entrambe le direzioni. Una connessione che riesce mentre un servizio vicino dovrebbe fallire è più informativa di un singolo ping riuscito, perché mostra che la politica è selettiva e non spalancata. Se il test che dovrebbe essere negato riesce, il colpevole non è il tunnel ma la politica. Conserva entrambi i risultati nel registro delle modifiche, così la persona successiva sa quale comportamento era voluto.

Hairpin o una seconda interfaccia

Il transito hairpin mantiene il progetto compatto e costa un'impostazione globale. Un'interfaccia separata, o un tunnel basato sull'instradamento con la propria interfaccia virtuale, isola il percorso di transito e ti dà una politica per interfaccia, al costo dell'indirizzamento e di un'altra crypto map o profilo. Nessuna delle due è più corretta; falliscono in modo diverso.

I progetti basati sull'instradamento sono una disposizione diversa, non una casella di controllo nella stessa configurazione. Se passi a uno di essi, la discussione sull'ACL di crittografia basata su policy qui sopra smette di valere e la tabella di routing inizia a fare il lavoro di selezione.

Verifica dal client reale

Una sonda avviata dall'ASA ha un indirizzo di origine diverso e non percorrerà il cammino dal pool alla filiale. Usa packet-tracer per controllare la quintupla, poi apri una connessione reale dal client remoto effettivo, perché il tracer simula e non sostituisce l'instradamento e la politica del client stesso.

Dopo una modifica pianificata, connettiti a un servizio che dovrebbe funzionare, poi a uno che dovrebbe essere negato, quindi conferma la rotta di ritorno della filiale. Gli esempi di NAT hairpin per VPN di Cisco mantengono il permesso intra-interface, il NAT e le ACL visibilmente separati, e questo è il modello mentale che vale la pena copiare.