Tunelul divizat nu scutește un host public de regulile NAT ale ASA

O rută split-include trage un host public în tunel, unde ASA trebuie să facă hairpin și să traducă sursa. Sari peste oricare dintre cei doi pași și fluxul cade.

Tunelul divizat este de obicei descris ca o modalitate de a ține traficul corporativ în interiorul tunelului și restul internetului în afara firewall-ului. Ambele jumătăți ale acestei descrieri sunt greșite în același fel. Tunelul divizat este o decizie de rutare luată de client, iar o decizie de rutare nu spune nimic despre ce se întâmplă cu pachetul după ce ajunge la headend.

Un singur serviciu de partener pe o adresă publică, care insistă să vadă adresa sediului tău, este suficient pentru a dărâma povestea.

Mitul: tunelul divizat scoate firewall-ul din cale

Convingerea este că orice destinație din afara intervalelor private rămâne pe conexiunea locală la internet, așa că firewall-ul nu o vede niciodată și nu are niciodată nevoie de o regulă pentru ea. Asta este valabil doar cât timp destinația nu este în lista tunelului. În momentul în care un operator adaugă un host public în ACL-ul split-include, clientul trimite acel trafic în tunel, iar ASA trebuie să îl ruteze, să îl filtreze și să îl traducă precum orice alt flux decriptat. Pe client nu s-a schimbat nimic în afară de lista de destinații.

Clientul nu a devenit un router. A urmat politica pe care i-ai dat-o.

Ce face de fapt o rută split-include

Într-o configurare de acces la distanță Cisco ASA, politica de grup poartă split-tunnel-policy tunnelspecified și o split-tunnel-network-list care numește un ACL standard. Fiecare linie permit din acel ACL este o destinație pe care clientul trebuie să o trimită în tunel, iar tot restul continuă să folosească ruta implicită locală.

Adăugarea unui host este o singură linie și este singura parte a schimbării pe care clientul o poate vedea: access-list RA-SPLIT standard permit host 203.0.113.20.

Reconectează clientul după aceea. Politica este schimbată la conectare, așa că o sesiune deja stabilită păstrează lista veche și face schimbarea să pară că nu a făcut nimic.

Pachetul intră și iese pe aceeași interfață

Urmărește acum fluxul după decriptare. Pachetul a intrat pe interfața exterioară prin tunelul VPN, destinația lui este o adresă publică, iar tabela de rutare îl trimite înapoi pe aceeași interfață exterioară spre internet. Traficul care intră și iese pe o singură interfață este aruncat dacă ASA nu este lăsat să permită asta, și exact asta face same-security-traffic permit intra-interface. Fără el, conexiunea eșuează într-un mod care pare o problemă de rutare și nu este.

Această setare este globală. Permite hairpinning pentru fiecare flux care are nevoie, nu doar pentru acest host partener, deci aparține unei schimbări revizuite, nu unui test rapid.

De ce un PAT limitat la destinație nu este opțional

Adresa sursă din pachetul decriptat este încă adresa VPN a clientului, de obicei dintr-un pool precum 10.77.0.0/24. Acea adresă nu are rută în internetul public, așa că partenerul fie nu răspunde niciodată, fie răspunde în gol.

Traducerea corectează sursa și lasă destinația neatinsă. Deoarece obiectele sunt deja definite altundeva, o regulă manuală limitată la această destinație are această formă:

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

Partea destination static contează. Dacă o omiți, regula devine o traducere largă care poate potrivi mult mai mult trafic decât s-a intenționat, iar o regulă identity largă aflată mai devreme în ordine o poate învinge complet. Verifică show nat detail și ordinea secțiunilor înainte de a presupune că regula ta este cea care potrivește.

PAT-ul de interfață înseamnă și că partenerul vede adresa interfeței ASA, care poate fi tradusă din nou mai sus. Dacă contractul numește o adresă, confirmă-o de la un capăt la altul, nu la un singur salt.

Demonstrează cu destinația de test corectă

Folosește hostul partener însuși, nu o pagină generică what-is-my-ip. Acea pagină este aproape sigur în afara listei split, așa că raportează adresa ta locală de internet și nu spune nimic despre această cale. Deschide o conexiune nouă către serviciul partenerului și întreabă ce sursă au observat, sau rulează packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed și citește etapele NAT și de rutare linie cu linie. Un traceroute de la client este o verificare mai slabă, pentru că arată calea care s-a întâmplat deja, nu politica ce a ales-o.

Apoi verifică ce nu trebuie să se schimbe. Un site web obișnuit trebuie să iasă în continuare prin conexiunea locală, iar o resursă privată din lista tunelului trebuie să rămână accesibilă. O schimbare care repară partenerul și strică una dintre cele două este alt bug.

Versiunea care funcționează a acestui design este scurtă: un host în ACL-ul split, permisiune hairpin, o regulă PAT limitată la destinație. Tot restul poveștii este mitul.

Articole similare