Hindi inihihiwalay ng paghahati ng tunnel ang pampublikong host sa mga panuntunan ng NAT ng ASA

Ang split tunnel ay karaniwang inilalarawan bilang paraan upang panatilihin ang trapiko ng kumpanya sa loob ng tunnel at ang natitirang internet sa labas ng firewall. Mali ang dalawang kalahati ng paglalarawang iyon sa parehong paraan. Ang split tunnel ay desisyon sa ruta na ginagawa ng kliyente, at ang desisyon sa ruta ay walang sinasabi tungkol sa nangyayari sa packet pagkatapos nitong maabot ang headend.

Isang serbisyo ng partner sa pampublikong address, na nagpipilit na makita ang address ng iyong punong tanggapan, ay sapat na upang gibain ang kuwentong ito.

Mito: inaalis ng split tunnel ang firewall sa landas

Ang paniniwala ay ang anumang destinasyon sa labas ng mga pribadong saklaw ay nananatili sa lokal na koneksyon sa internet, kaya hindi ito nakikita ng firewall at hindi kailanman nangangailangan ng panuntunan para rito. Totoo lamang ito habang wala ang destinasyon sa listahan ng tunnel. Sa sandaling magdagdag ang operator ng pampublikong host sa ACL na split-include, ipinapadala ng kliyente ang trapikong iyon sa tunnel, at kailangang i-ruta, i-filter at isalin ito ng ASA tulad ng anumang iba pang na-decrypt na daloy. Wala nang nagbago sa kliyente maliban sa listahan ng destinasyon.

Hindi naging router ang kliyente. Sinunod nito ang patakarang ibinigay mo.

Ano ang talagang ginagawa ng rutang split-include

Sa isang setup ng remote access ng Cisco ASA, dala ng patakaran ng grupo ang split-tunnel-policy tunnelspecified at isang split-tunnel-network-list na nagpapangalan ng standard na ACL. Bawat linyang permit sa ACL na iyon ay destinasyong dapat ipadala ng kliyente sa tunnel, at lahat ng iba ay patuloy na gumagamit ng lokal na default na ruta.

Ang pagdaragdag ng isang host ay isang linya, at iyon lamang ang bahagi ng pagbabagong nakikita ng kliyente: access-list RA-SPLIT standard permit host 203.0.113.20.

Ikonekta muli ang kliyente pagkatapos. Ipinapalitan ang patakaran sa oras ng koneksyon, kaya pinananatili ng naitatag na sesyon ang lumang listahan at ginagawang parang walang ginawa ang pagbabago.

Pumapasok at lumalabas ang packet sa parehong interface

Sundan ngayon ang daloy pagkatapos ng decryption. Pumasok ang packet sa panlabas na interface sa pamamagitan ng VPN tunnel, pampublikong address ang destinasyon nito, at ipinapadala itong muli ng routing table sa parehong panlabas na interface patungo sa internet. Ang trapikong pumapasok at lumalabas sa isang interface ay itinatapon maliban kung papayagan ang ASA, at iyon ang ginagawa ng same-security-traffic permit intra-interface. Kung wala iyon, nabibigo ang koneksyon sa paraang mukhang problema sa routing pero hindi.

Ang setting na iyon ay global. Pinapayagan nito ang hairpinning para sa bawat daloy na nangangailangan, hindi lamang para sa partner host na ito, kaya kabilang ito sa isang sinuring pagbabago at hindi sa mabilisang pagsubok.

Bakit hindi opsyonal ang PAT na limitado sa destinasyon

Ang source address sa na-decrypt na packet ay address pa rin ng VPN ng kliyente, karaniwang mula sa pool tulad ng 10.77.0.0/24. Walang ruta ang address na iyon sa pampublikong internet, kaya ang partner ay maaaring hindi kailanman sumagot o sumagot sa wala.

Itinatama ng pagsasalin ang pinagmulan at hinahayaang hindi ginalaw ang destinasyon. Dahil naitakda na ang mga object sa ibang lugar, ang manu-manong panuntunang limitado sa destinasyong ito ay may ganitong anyo:

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

Mahalaga ang bahaging destination static. Kung aalisin mo ito, magiging malawak na pagsasalin ang panuntunan na maaaring tumugma sa mas maraming trapiko kaysa nilalayon, at ang malawak na panuntunang identity na nauna sa pagkakasunod-sunod ay maaaring talunin ito nang tuluyan. Suriin ang show nat detail at ang pagkakasunod-sunod ng mga seksyon bago ipagpalagay na ang panuntunan mo ang tumutugma.

Ang PAT sa interface ay nangangahulugan ding nakikita ng partner ang address ng interface ng ASA, na maaaring isalin muli sa itaas. Kung pinangalanan ng kontrata ang isang address, tiyakin ito mula simula hanggang dulo at hindi sa isang hop lamang.

Patunayan ito sa tamang destinasyon ng pagsubok

Gamitin ang partner host mismo, hindi ang pangkalahatang pahina ng what-is-my-ip. Halos tiyak na nasa labas ng listahan ng split ang pahinang iyon, kaya iniuulat nito ang lokal mong address sa internet at walang sinasabi tungkol sa landas na ito. Magbukas ng bagong koneksyon sa serbisyo ng partner at itanong kung anong pinagmulan ang nakita nila, o patakbuhin ang packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed at basahin ang mga yugto ng NAT at routing linya bawat linya. Ang traceroute mula sa kliyente ay mas mahinang pagsusuri, dahil ipinapakita nito ang landas na nangyari na, hindi ang patakarang pumili nito.

Pagkatapos ay suriin kung ano ang hindi dapat magbago. Ang ordinaryong website ay dapat pa ring lumabas sa lokal na koneksyon, at ang pribadong resource sa listahan ng tunnel ay dapat pa ring maabot. Ang pagbabagong nag-aayos sa partner at sumisira sa alinman sa dalawang iyon ay ibang bug.

Ang gumaganang bersyon ng disenyong ito ay maikli: isang host sa ACL split, pahintulot sa hairpin, isang panuntunang PAT na limitado sa destinasyon. Ang lahat ng iba sa kuwento ay ang mito.