Lo split tunneling non esenta un host pubblico dalle regole NAT dell’ASA

Lo split tunneling è di solito descritto come un modo per tenere il traffico aziendale dentro il tunnel e il resto di Internet fuori dal firewall. Entrambe le metà di questa descrizione sono sbagliate allo stesso modo. Lo split tunneling è una decisione di routing presa dal client, e una decisione di routing non dice nulla su cosa accade al pacchetto dopo che raggiunge l’headend.

Un solo servizio partner su un indirizzo pubblico, che insiste nel vedere l’indirizzo della tua sede, basta a far cadere il racconto.

Il mito: lo split tunnel toglie il firewall dal percorso

La convinzione è che qualsiasi destinazione fuori dagli intervalli privati resti sulla connessione Internet locale, così il firewall non la vede mai e non ha mai bisogno di una regola per lei. Questo vale solo finché la destinazione non è nella lista del tunnel. Nel momento in cui un operatore aggiunge un host pubblico all’ACL split-include, il client invia quel traffico nel tunnel, e l’ASA deve instradarlo, filtrarlo e tradurlo come qualsiasi altro flusso decifrato. Sul client non è cambiato nulla tranne la lista delle destinazioni.

Il client non è diventato un router. Ha seguito la politica che gli hai dato.

Cosa fa davvero una rotta split-include

In una configurazione di accesso remoto Cisco ASA, la politica di gruppo porta split-tunnel-policy tunnelspecified e un split-tunnel-network-list che nomina un’ACL standard. Ogni riga permit di quell’ACL è una destinazione che il client deve inviare nel tunnel, e tutto il resto continua a usare la rotta predefinita locale.

Aggiungere un host è una sola riga, ed è l’unica parte della modifica che il client può vedere: access-list RA-SPLIT standard permit host 203.0.113.20.

Riconnetti il client dopo. La politica viene scambiata al momento della connessione, quindi una sessione già stabilita mantiene la vecchia lista e fa sembrare che la modifica non abbia fatto nulla.

Il pacchetto arriva ed esce dalla stessa interfaccia

Ora segui il flusso dopo la decifratura. Il pacchetto è entrato dall’interfaccia esterna attraverso il tunnel VPN, la sua destinazione è un indirizzo pubblico, e la tabella di routing lo rimanda fuori dalla stessa interfaccia esterna verso Internet. Il traffico che entra ed esce da una sola interfaccia viene scartato a meno che all’ASA sia permesso, ed è ciò che fa same-security-traffic permit intra-interface. Senza di esso la connessione fallisce in un modo che sembra un problema di routing e non lo è.

Quell’impostazione è globale. Consente l’hairpinning per ogni flusso che ne ha bisogno, non solo per questo host partner, quindi appartiene a una modifica rivista e non a un test rapido.

Perché un PAT limitato alla destinazione non è opzionale

L’indirizzo di origine del pacchetto decifrato è ancora l’indirizzo VPN del client, di solito da un pool come 10.77.0.0/24. Quell’indirizzo non ha una rotta su Internet pubblico, quindi il partner o non risponde mai o risponde a nessuno.

La traduzione corregge la sorgente e lascia la destinazione intatta. Poiché gli oggetti sono già definiti altrove, una regola manuale limitata a questa destinazione ha questa forma:

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

La parte destination static conta. Se la ometti, la regola diventa una traduzione ampia che può corrispondere a molto più traffico del previsto, e una regola identity ampia precedente nell’ordine può batterla del tutto. Controlla show nat detail e l’ordine delle sezioni prima di supporre che la tua regola sia quella che corrisponde.

Il PAT di interfaccia significa anche che il partner vede l’indirizzo dell’interfaccia dell’ASA, che può essere tradotto di nuovo più a monte. Se il contratto nomina un indirizzo, confermalo da un capo all’altro invece che a un solo hop.

Provalo con la destinazione di test giusta

Usa l’host partner stesso, non una pagina what-is-my-ip generica. Quella pagina è quasi certamente fuori dalla lista split, quindi riporta il tuo indirizzo Internet locale e non dice nulla su questo percorso. Apri una nuova connessione al servizio partner e chiedi quale sorgente hanno osservato, oppure esegui packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed e leggi le fasi NAT e di routing riga per riga. Un traceroute dal client è un controllo più debole, perché mostra il percorso che è già avvenuto e non la politica che lo ha scelto.

Poi controlla cosa non deve cambiare. Un sito web normale deve continuare a uscire dalla connessione locale, e una risorsa privata nella lista del tunnel deve restare raggiungibile. Una modifica che sistema il partner e rompe una delle due è un altro bug.

La versione funzionante di questo progetto è breve: un host nell’ACL split, permesso hairpin, una regola PAT limitata alla destinazione. Tutto il resto della storia è il mito.