Split-tunelo ne esceptas publikan gastiganton de la NAT-reguloj de ASA
Split-include vojo tiras publikan gastiganton en la tunelon, kie ASA devas apliki hairpin kaj traduki la fonton. Mankigu ajnan el la du paŝoj kaj la fluo falas.
Split-tunelado estas kutime priskribata kiel maniero teni korporacian trafikon ene de la tunelo kaj la ceterajn partojn de la interreto ekster la fajroŝirmilo. Ambaŭ duonoj de tiu priskribo malĝustas sammaniere. Split-tunelado estas voj-decido farata de la kliento, kaj voj-decido diras nenion pri tio, kio okazas al la pako post kiam ĝi atingas la headend.
Unu partnera servo sur publika adreso, kiu insistas vidi la adreson de via ĉefsidejo, sufiĉas por detrui la rakonton.
La mito: split-tunelo forigas la fajroŝirmilon el la vojo
La kredo estas, ke ajna celo ekster la privataj gamoj restas sur la loka interreta konekto, do la fajroŝirmilo neniam vidas ĝin kaj neniam bezonas regulon por ĝi. Tio validas nur dum la celo forestas el la tunela listo. En la momento, kiam administranto aldonas publikan gastiganton al la split-include ACL, la kliento sendas tiun trafikon en la tunelon, kaj ASA devas enkursigi, filtri kaj traduki ĝin kiel ajnan alian malĉifritan fluon. Nenio ŝanĝiĝis en la kliento krom la cellisto.
La kliento ne fariĝis enkursigilo. Ĝi sekvis la politikon, kiun vi donis al ĝi.
Kion split-include vojo vere faras
En Cisco ASA agordo por fora aliro, la grupa politiko portas split-tunnel-policy tunnelspecified kaj split-tunnel-network-list, kiu nomas norman ACL. Ĉiu permit-linio en tiu ACL estas celo, kiun la kliento devas sendi en la tunelon, kaj ĉio alia daŭre uzas la lokan implicitan vojon.
Aldoni unu gastiganton estas unu linio, kaj ĝi estas la sola parto de la ŝanĝo, kiun la kliento povas vidi: access-list RA-SPLIT standard permit host 203.0.113.20.
Poste rekonektu la klienton. La politiko interŝanĝiĝas ĉe konekto, do establita seanco konservas la malnovan liston kaj igas la ŝanĝon aspekti kvazaŭ ĝi faris nenion.
La pako alvenas kaj foriras sur la sama interfaco
Nun spuru la fluon post malĉifrado. La pako eniris sur la ekstera interfaco tra la VPN-tunelo, ĝia celo estas publika adreso, kaj la enkursiga tabelo sendas ĝin reen tra tiu sama ekstera interfaco al la interreto. Trafiko, kiu eniras kaj eliras unu interfacon, estas forĵetata krom se ASA rajtas permesi ĝin, kaj tion faras same-security-traffic permit intra-interface. Sen ĝi la konekto malsukcesas tiel, kio aspektas kiel enkursiga problemo kaj ne estas.
Tiu agordo estas tutmonda. Ĝi permesas hairpinning por ĉiu fluo, kiu bezonas ĝin, ne nur por ĉi tiu partnera gastiganto, do ĝi apartenas al reviziita ŝanĝo anstataŭ al rapida testo.
Kial PAT limigita al la celo ne estas laŭvola
La fonta adreso de la malĉifrita pako ankoraŭ estas la VPN-adreso de la kliento, kutime el pulo kiel 10.77.0.0/24. Tiu adreso havas neniun vojon en la publika interreto, do la partnero aŭ neniam respondas aŭ respondas en la nenien.
La traduko korektas la fonton kaj lasas la celon netuŝita. Ĉar la objektoj jam estas difinitaj aliloke, permana regulo limigita al ĉi tiu celo havas ĉi tiun formon:
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_HOSTLa parto destination static gravas. Se vi forigas ĝin, la regulo fariĝas larĝa traduko, kiu povas kongrui kun multe pli da trafiko ol celite, kaj larĝa identity-regulo pli frue en la ordo povas venki ĉi tiun tute. Kontrolu show nat detail kaj la sekcian ordon antaŭ ol supozi, ke via regulo estas la kongruanta.
Interfaca PAT ankaŭ signifas, ke la partnero vidas la interfacan adreson de ASA, kiu povas esti tradukita denove pli supre. Se la kontrakto nomas adreson, konfirmu ĝin de finpunkto al finpunkto anstataŭ ĉe unu salto.
Pruvu ĝin per la ĝusta testa celo
Uzu la partneran gastiganton mem, ne ĝeneralan paĝon what-is-my-ip. Tiu paĝo preskaŭ certe estas ekster la split-listo, do ĝi raportas vian lokan interretan adreson kaj diras nenion pri ĉi tiu vojo. Malfermu novan konekton al la partnera servo kaj demandu ilin, kian fonton ili observis, aŭ rulu packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed kaj legu la NAT- kaj enkursigajn etapojn linio post linio. Traceroute el la kliento estas pli malforta kontrolo, ĉar ĝi montras la vojon, kiu jam okazis, anstataŭ la politikon, kiu elektis ĝin.
Poste kontrolu, kio ne devas ŝanĝiĝi. Ordinara retejo devas daŭre eliri el la loka konekto, kaj privata rimedo en la tunela listo devas daŭre esti atingebla. Ŝanĝo, kiu riparas la partneron kaj rompas unu el tiuj du, estas alia cimo.
La funkcianta versio de ĉi tiu dezajno estas mallonga: unu gastiganto en la split-ACL, hairpin-permeso, unu PAT-regulo limigita al la celo. Ĉio alia en la rakonto estas la mito.