Split-tunnel fritager ikke en offentlig vært for ASA'ens NAT-regler

Split-tunnel beskrives normalt som en måde at holde virksomhedstrafik inde i tunnelen og resten af internettet uden for firewallen. Begge halvdele af den beskrivelse er forkerte på samme måde. Split-tunnel er en rutebeslutning, som klienten træffer, og en rutebeslutning siger intet om, hvad der sker med pakken, efter den når headend.

Én partnertjeneste på en offentlig adresse, som insisterer på at se din hovedkontoradresse, er nok til at vælte historien.

Myten: split-tunnel fjerner firewalled fra vejen

Troen er, at enhver destination uden for de private områder bliver på den lokale internetforbindelse, så firewalled aldrig ser den og aldrig har brug for en regel til den. Det gælder kun, så længe destinationen ikke står på tunnelisten. I det øjeblik en operatør tilføjer en offentlig vært til split-include-ACL'en, sender klienten trafikken ind i tunnelen, og ASA'en skal route, filtrere og oversætte den som ethvert andet dekrypteret flow. Intet er ændret på klienten undtagen destinationslisten.

Klienten blev ikke en router. Den fulgte den politik, du gav den.

Hvad en split-include-rute faktisk gør

I et Cisco ASA-fjerntligangsopsætning bærer gruppepolitikken split-tunnel-policy tunnelspecified og en split-tunnel-network-list, som navngiver en standard-ACL. Hver permit-linje i den ACL er en destination, klienten skal sende ind i tunnelen, og alt andet bruger fortsat den lokale standardrute.

At tilføje én vært er én linje, og det er den eneste del af ændringen, klienten kan se: access-list RA-SPLIT standard permit host 203.0.113.20.

Genopret klienten bagefter. Politikken udveksles ved forbindelse, så en etableret session beholder den gamle liste og får ændringen til at se ud, som om den intet gjorde.

Pakken ankommer og forlader samme interface

Spor nu flowet efter dekryptering. Pakken kom ind på det ydre interface gennem VPN-tunnelen, dens destination er en offentlig adresse, og routingtabellen sender den ud igen gennem samme ydre interface mod internettet. Trafik, der kommer ind og ud ad ét interface, droppes, medmindre ASA'en får lov at tillade det, og det er, hvad same-security-traffic permit intra-interface gør. Uden det fejler forbindelsen på en måde, der ligner et routingproblem, men ikke er det.

Den indstilling er global. Den tillader hairpinning for ethvert flow, der har brug for det, ikke kun for denne partner-vært, så den hører i en gennemgået ændring og ikke i en hurtig test.

Hvorfor en destinationsafgrænset PAT ikke er valgfri

Kildeadressen på den dekrypterede pakke er stadig klientens VPN-adresse, typisk fra en pulje som 10.77.0.0/24. Den adresse har ingen rute på det offentlige internet, så partneren svarer enten aldrig eller svarer ud i ingenting.

Oversættelsen retter kilden og lader destinationen være urørt. Da objekterne allerede er defineret andre steder, har en manuel regel afgrænset til denne destination denne 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

Delen destination static er vigtig. Udelader man den, bliver reglen en bred oversættelse, der kan matche langt mere trafik end tilsigtet, og en bred identity-regel tidligere i rækkefølgen kan slå denne fuldstændigt. Kontrollér show nat detail og sektionsrækkefølgen, før du antager, at din regel er den, der matcher.

Interface-PAT betyder også, at partneren ser ASA'ens interfaceadresse, som kan blive oversat igen længere oppe. Hvis kontrakten angiver en adresse, skal du bekræfte den ende til ende i stedet for ved et enkelt hop.

Bevis det med den rigtige testdestination

Brug partnerens vært selv, ikke en generisk what-is-my-ip-side. Den side ligger næsten helt sikkert uden for split-listen, så den rapporterer din lokale internetadresse og siger intet om denne vej. Åbn en ny forbindelse til partnertjenesten, og spørg dem, hvilken kilde de så, eller kør packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed og læs NAT- og routingtrinnene linje for linje. En traceroute fra klienten er en svagere kontrol, fordi den viser den vej, der allerede er sket, i stedet for den politik, der valgte den.

Kontrollér derefter, hvad der ikke må ændre sig. Et almindeligt websted skal stadig gå ud ad den lokale forbindelse, og en privat ressource på tunnelisten skal stadig være tilgængelig. En ændring, der retter partneren og brækker en af de to, er en anden fejl.

Den fungerende version af dette design er kort: én vært i split-ACL'en, hairpin-tilladelse, én destinationsafgrænset PAT-regel. Alt andet i historien er myten.