Split-tunnel fritar ikke en offentlig vert fra ASA-ens NAT-regler

Split-tunnel beskrives vanligvis som en måte å holde virksomhetstrafikk inne i tunnelen og resten av internett utenfor brannmuren. Begge halvdelene av den beskrivelsen er feil på samme måte. Split-tunnel er en rutebeslutning som klienten tar, og en rutebeslutning sier ingenting om hva som skjer med pakken etter at den når headend.

Én partnertjeneste på en offentlig adresse, som insisterer på å se hovedkontoradressen din, er nok til å velte historien.

Myten: split-tunnel fjerner brannmuren fra veien

Troen er at enhver destinasjon utenfor de private områdene blir værende på den lokale internettforbindelsen, slik at brannmuren aldri ser den og aldri trenger en regel for den. Det gjelder bare så lenge destinasjonen ikke står på tunnellisten. I det øyeblikket en operatør legger til en offentlig vert i split-include-ACL-en, sender klienten trafikken inn i tunnelen, og ASA-en må rute, filtrere og oversette den som enhver annen dekryptert flyt. Ingenting er endret på klienten bortsett fra destinasjonslisten.

Klienten ble ikke en ruter. Den fulgte policyen du ga den.

Hva en split-include-rute faktisk gjør

I et Cisco ASA-oppsett for fjernaksess bærer gruppepolicyen split-tunnel-policy tunnelspecified og en split-tunnel-network-list som navngir en standard-ACL. Hver permit-linje i den ACL-en er en destinasjon klienten skal sende inn i tunnelen, og alt annet bruker fortsatt den lokale standardruten.

Å legge til én vert er én linje, og det er den eneste delen av endringen klienten kan se: access-list RA-SPLIT standard permit host 203.0.113.20.

Koble klienten til på nytt etterpå. Policyen utveksles ved tilkobling, så en etablert økt beholder den gamle listen og får endringen til å se ut som om den ikke gjorde noe.

Pakken kommer inn og går ut på samme grensesnitt

Følg nå flyten etter dekryptering. Pakken kom inn på det ytre grensesnittet gjennom VPN-tunnelen, destinasjonen er en offentlig adresse, og rutetabellen sender den ut igjen gjennom samme ytre grensesnitt mot internett. Trafikk som kommer inn og går ut på ett grensesnitt, blir droppet med mindre ASA-en får lov til å tillate det, og det er det same-security-traffic permit intra-interface gjør. Uten det feiler forbindelsen på en måte som ser ut som et ruteproblem, men ikke er det.

Den innstillingen er global. Den tillater hairpinning for hver flyt som trenger det, ikke bare for denne partnerverten, så den hører hjemme i en gjennomgått endring og ikke i en hurtigtest.

Hvorfor en destinasjonsavgrenset PAT ikke er valgfri

Kildeadressen på den dekrypterte pakken er fortsatt klientens VPN-adresse, typisk fra en pool som 10.77.0.0/24. Den adressen har ingen rute på det offentlige internettet, så partneren svarer enten aldri eller svarer ut i ingenting.

Oversettelsen retter kilden og lar destinasjonen være urørt. Siden objektene allerede er definert andre steder, har en manuell regel avgrenset til denne destinasjonen denne formen:

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 viktig. Utelater man den, blir regelen en bred oversettelse som kan matche langt mer trafikk enn tiltenkt, og en bred identity-regel tidligere i rekkefølgen kan slå denne fullstendig. Kontroller show nat detail og rekkefølgen på seksjonene før du antar at din regel er den som matcher.

Interface-PAT betyr også at partneren ser ASA-ens grensesnittadresse, som kan bli oversatt på nytt lenger oppe. Hvis kontrakten navngir en adresse, bekreft den ende til ende i stedet for ved ett enkelt hopp.

Bevis det med riktig testdestinasjon

Bruk partnerverten selv, ikke en generisk what-is-my-ip-side. Den siden ligger nesten helt sikkert utenfor split-listen, så den rapporterer din lokale internettadresse og sier ingenting om denne veien. Åpne en ny forbindelse til partnertjenesten og spør hvilken kilde de så, eller kjør packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed og les NAT- og rutetrinnene linje for linje. En traceroute fra klienten er en svakere kontroll, fordi den viser veien som allerede har skjedd, ikke policyen som valgte den.

Sjekk deretter hva som ikke skal endres. Et vanlig nettsted må fortsatt gå ut over den lokale forbindelsen, og en privat ressurs på tunnellisten må fortsatt være tilgjengelig. En endring som fikser partneren og bryter en av de to, er en annen feil.

Den fungerende versjonen av dette designet er kort: én vert i split-ACL-en, hairpin-tillatelse, én destinasjonsavgrenset PAT-regel. Alt annet i historien er myten.