Split-tunnel vert vanlegvis skildra som ein måte å halde verksemdstrafikk inne i tunnelen og resten av internett utanfor brannmuren. Båe halvdelane av den skildringa er feil på same måte. Split-tunnel er eit rutevedtak som klienten tek, og eit rutevedtak seier ingenting om kva som skjer med pakken etter at han når headend.

Éin partnarteneste på ei offentleg adresse, som insisterer på å sjå hovudkontoradressa di, er nok til å velte historia.

Myten: split-tunnel fjernar brannmuren frå vegen

Trua er at kvar destinasjon utanfor dei private områda blir verande på den lokale internettilkoplinga, slik at brannmuren aldri ser han og aldri treng ein regel for han. Det gjeld berre så lenge destinasjonen ikkje står på tunnellista. I det augneblinken ein operatør legg til ein offentleg vert i split-include-ACL-en, sender klienten trafikken inn i tunnelen, og ASA-en må rute, filtrere og omsetje han som ein kvar annan dekryptert flyt. Ingenting er endra på klienten bortsett frå destinasjonslista.

Klienten vart ikkje ein ruter. Han fylgde policyen du gav han.

Kva ei split-include-rute faktisk gjer

I eit Cisco ASA-oppsett for fjernaksess ber gruppepolicyen split-tunnel-policy tunnelspecified og ein split-tunnel-network-list som namngjev ein standard-ACL. Kvar permit-linje i den ACL-en er ein destinasjon klienten skal sende inn i tunnelen, og alt anna brukar framleis den lokale standardruta.

Å leggje til éin vert er éi linje, og det er den einaste delen av endringa klienten kan sjå: access-list RA-SPLIT standard permit host 203.0.113.20.

Kopla klienten til på nytt etterpå. Policyen vert utveksla ved tilkopling, så ei etablert økt held på den gamle lista og får endringa til å sjå ut som om ho ikkje gjorde noko.

Pakken kjem inn og går ut på same grensesnitt

Fylg no flyten etter dekryptering. Pakken kom inn på det ytre grensesnittet gjennom VPN-tunnelen, destinasjonen er ei offentleg adresse, og rutetabellen sender han ut att gjennom same ytre grensesnitt mot internett. Trafikk som kjem inn og går ut på eitt grensesnitt, vert droppa med mindre ASA-en får lov til å tillate det, og det er det same-security-traffic permit intra-interface gjer. Utan det feilar sambandet på ein måte som ser ut som eit ruteproblem, men ikkje er det.

Den innstillinga er global. Ho tillèt hairpinning for kvar flyt som treng det, ikkje berre for denne partnervierten, så ho høyrer heime i ei gjennomgått endring og ikkje i ein hurtigtest.

Kvifor ein destinasjonsavgrensa PAT ikkje er valfri

Kjeldeadressa på den dekrypterte pakken er framleis VPN-adressa til klienten, typisk frå ein pool som 10.77.0.0/24. Den adressa har inga rute på det offentlege internettet, så partnaren svarar anten aldri eller svarar ut i inkje.

Omsetjinga rettar kjelda og lèt destinasjonen vere urørd. Sidan objekta allereie er definerte andre stader, har ein manuell regel avgrensa til denne destinasjonen denne 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

Delen destination static er viktig. Utelèt ein han, blir regelen ei brei omsetjing som kan matche langt meir trafikk enn tiltenkt, og ein brei identity-regel tidlegare i rekkjefylgja kan slå denne fullstendig. Kontroller show nat detail og rekkjefylgja på seksjonane før du går ut frå at din regel er den som matchar.

Interface-PAT tyder òg at partnaren ser grensesnittadressa til ASA-en, som kan bli omsett på nytt lenger oppe. Viss kontrakten namngjev ei adresse, stadfest ho frå ende til ende i staden for ved eitt enkelt hopp.

Prov det med rett testdestinasjon

Bruk partnervierten sjølv, ikkje ei generisk what-is-my-ip-side. Den sida ligg nesten heilt sikkert utanfor split-lista, så ho rapporterer den lokale internettadressa di og seier ingenting om denne vegen. Opne ei ny tilkopling til partnartenesta og spør kva kjelde dei såg, eller køyr packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed og les NAT- og rutetrinna linje for linje. Ein traceroute frå klienten er ein svakare kontroll, fordi han viser vegen som allereie har skjedd, ikkje policyen som valde han.

Sjekk deretter kva som ikkje skal endrast. Eit vanleg nettstad må framleis gå ut over den lokale tilkoplinga, og ein privat ressurs på tunnellista må framleis vere tilgjengeleg. Ei endring som fiksar partnaren og bryt ein av dei to, er ein annan feil.

Den fungerande versjonen av dette designet er kort: éin vert i split-ACL-en, hairpin-løyve, éin destinasjonsavgrensa PAT-regel. Alt anna i historia er myten.

Relaterte artiklar