Tuneli i ndarë nuk e përjashton një host publik nga rregullat NAT të ASA-s

Tuneli i ndarë zakonisht përshkruhet si një mënyrë për të mbajtur trafikun e korporatës brenda tunelit dhe pjesën tjetër të internetit jashtë firewall-it. Të dyja gjysmat e këtij përshkrimi janë të gabuara në të njëjtën mënyrë. Tuneli i ndarë është një vendim rruge që merr klienti, dhe një vendim rruge nuk thotë asgjë për atë që ndodh me paketën pasi ajo arrin në headend.

Një shërbim i vetëm partneri në një adresë publike, që këmbëngul të shohë adresën e selisë suaj, mjafton për ta rrëzuar këtë histori.

Miti: tuneli i ndarë e heq firewall-in nga rruga

Besimi është se çdo destinacion jashtë intervaleve private mbetet në lidhjen lokale të internetit, kështu që firewall-i nuk e sheh kurrë dhe nuk ka kurrë nevojë për një rregull për të. Kjo vlen vetëm për sa kohë destinacioni nuk është në listën e tunelit. Në momentin që një operator shton një host publik në ACL-në split-include, klienti e dërgon atë trafik brenda tunelit, dhe ASA duhet ta rutojë, ta filtrojë dhe ta përkthejë si çdo fluks tjetër të dekriptuar. Në klient nuk ka ndryshuar asgjë përveç listës së destinacioneve.

Klienti nuk u bë router. Ai ndoqi politikën që i dhatë.

Çfarë bën në të vërtetë një rrugë split-include

Në një konfigurim aksesi në distancë Cisco ASA, politika e grupit mban split-tunnel-policy tunnelspecified dhe një split-tunnel-network-list që emërton një ACL standarde. Çdo rresht permit në atë ACL është një destinacion që klienti duhet ta dërgojë në tunel, dhe gjithçka tjetër vazhdon të përdorë rrugën standarde lokale.

Shtimi i një hosti është një rresht i vetëm, dhe është e vetmja pjesë e ndryshimit që klienti mund të shohë: access-list RA-SPLIT standard permit host 203.0.113.20.

Rilidhni klientin pas kësaj. Politika shkëmbehet në momentin e lidhjes, kështu që një sesion i vendosur mban listën e vjetër dhe e bën ndryshimin të duket sikur nuk bëri asgjë.

Paketa hyn dhe del në të njëjtin ndërfaqe

Tani ndiqni fluksin pas dekriptimit. Paketa hyri në ndërfaqen e jashtme përmes tunelit VPN, destinacioni i saj është një adresë publike, dhe tabela e rrugëzimit e dërgon atë përsëri jashtë nëpërmjet të njëjtës ndërfaqe të jashtme drejt internetit. Trafiku që hyn dhe del në një ndërfaqe hidhet poshtë nëse ASA nuk lejohet ta lejojë, dhe pikërisht këtë bën same-security-traffic permit intra-interface. Pa këtë, lidhja dështon në një mënyrë që duket problem rrugëzimi dhe nuk është.

Ajo cilësim është global. Lejon hairpinning për çdo fluks që ka nevojë, jo vetëm për këtë host partneri, prandaj i përket një ndryshimi të shqyrtuar dhe jo një testi të shpejtë.

Pse një PAT i kufizuar në destinacion nuk është opsional

Adresa e burimit në paketën e dekriptuar është ende adresa VPN e klientit, zakonisht nga një pishinë si 10.77.0.0/24. Ajo adresë nuk ka rrugë në internetin publik, kështu që partneri ose nuk përgjigjet kurrë ose përgjigjet askund.

Përkthimi korrigjon burimin dhe e lë destinacionin të paprekur. Meqenëse objektet janë përcaktuar tashmë diku tjetër, një rregull manual i kufizuar në këtë destinacion ka këtë 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

Pjesa destination static ka rëndësi. Nëse e hiqni, rregulli bëhet një përkthim i gjerë që mund të përputhet me shumë më tepër trafik sesa synohej, dhe një rregull identity i gjerë më herët në rend mund ta mundë plotësisht këtë. Kontrolloni show nat detail dhe rendin e seksioneve përpara se të supozoni se rregulli juaj është ai që përputhet.

PAT i ndërfaqes gjithashtu do të thotë që partneri sheh adresën e ndërfaqes së ASA-s, e cila mund të përkthehet përsëri më lart. Nëse kontrata emërton një adresë, konfirmojeni nga fillimi në fund dhe jo në një hop të vetëm.

Provojeni me destinacionin e duhur të testimit

Përdorni vetë hostin e partnerit, jo një faqe të përgjithshme what-is-my-ip. Ajo faqe është pothuajse me siguri jashtë listës split, kështu që raporton adresën tuaj lokale të internetit dhe nuk thotë asgjë për këtë rrugë. Hapni një lidhje të re me shërbimin e partnerit dhe pyesni çfarë burimi vëzhguan, ose ekzekutoni packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed dhe lexoni fazat e NAT dhe të rrugëzimit rresht për rresht. Një traceroute nga klienti është një kontroll më i dobët, sepse tregon rrugën që ndodhi tashmë, jo politikën që e zgjodhi.

Pastaj kontrolloni çfarë nuk duhet të ndryshojë. Një faqe e zakonshme web duhet të dalë ende nga lidhja lokale, dhe një burim privat në listën e tunelit duhet të mbetet i arritshëm. Një ndryshim që rregullon partnerin dhe prish njërën nga këto dy është një bug tjetër.

Versioni që funksionon i këtij dizajni është i shkurtër: një host në ACL-në split, leje hairpin, një rregull PAT i kufizuar në destinacion. Çdo gjë tjetër në këtë histori është miti.