Aling interface ang may NAT sa loob at labas sa labasan ng IOS VPN

Ang mga router na nagbibigay ng full-tunnel internet exit ay gumagawa ng dalawang trabahong mukhang isa. Tinatapos nito ang tunnel at ipinapasa ang na-decrypt na packet ng client papunta sa internet. Ang ikalawang trabaho lang ang kailangan ng pagsasalin, at dapat tumugma ang pagsasalin sa panloob na daloy. Ang pagkakaibang iyon ang nagtatakda kung aling mga interface ang may mga tungkulin ng NAT at anong hanay ng address ang lumalabas sa panuntunan.

Sundan ang isang packet sa router

Kumuha ng client sa 10.90.0.25 na nagbubukas ng pampublikong serbisyong HTTPS. Kung papasok ba ang destinasyong iyon sa tunnel ay desisyon ng patakaran ng client mismo. Kapag pumasok, ide-decrypt ng router ang packet at ihahatid ito sa isang virtual interface, kung saan ito iruruta patungo sa pampublikong uplink.

Ang virtual interface na iyon ang loob ng pagsasalin. Ang pampublikong uplink ang labas. Kung baliktad o wala ang mga tungkulin, aalis ang packet na may pribadong source o itatapon bago pa ito isalin.

Itugma ang patakaran ng pagsasalin sa pool ng client

Dapat pangalanan ng panuntunan ng NAT ang hanay na aktuwal na natatanggap ng mga client, hindi ang LAN ng opisina na nagkataong nagbabahagi ng uplink. Ang panuntunang sumasaklaw lamang sa lokal na subnet ay nakakaligta sa malalayong client kahit pareho silang lumalabas sa iisang interface.

ip access-list extended NAT-TUNNEL
 permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overload

Ihiwalay ang mga eksepsiyon para sa pribadong site. Ang trapiko patungo sa panloob na destinasyon ay dapat panatilihin ang orihinal nitong source, kung hindi ay tutugon ang destinasyon sa isang address na hindi nito maabot at mabibigo ang pabalik na bahagi sa paraang mukhang routing loop.

Ilapat ang mga tungkulin sa aktuwal na mga interface sa na-deploy na disenyo. Ang piraso ng Virtual-Template na kinopya mula sa lumang sagot ng Easy VPN ay hindi kumpletong kasalukuyang configuration, at ang uri ng tunnel na ginagamit ang nagtatakda kung aling interface ang tumatanggap ng na-decrypt na packet.

Ihiwalay ang panlabas na transport at panloob na pagsasalin

Ang pagsasalin ng na-decrypt na source ng application ay hindi kaparehong operasyon ng pagtulak ng IKE o mga protektadong packet sa isang NAT device sa itaas. Binabago ng una ang nakikita ng internet bilang source ng kahilingan ng client; pinapanatili ng pangalawa ang tunnel na buhay sa isang middlebox.

Ang paghaluin ang mga ito ay nagdudulot ng dalawang klasikong pagkabigo. Ang router na nagsasalin ng sarili nitong tunnel transport ay sumisira sa ugnayan ng peer, samantalang ang router na hindi kailanman nagsasalin ng panloob na daloy ay nagpapasa ng pribadong address sa internet. Basahin kung aling daloy ang tinitingnan mo bago mag-edit ng panuntunan, at tingnan kung nanatiling nakaupo ang tunnel pagkatapos ng pagbabago. Ang panuntunang nag-aayos ng pag-browse habang pinapatumba ang tunnel ay inilipat ang problema sa halip na lutasin ito.

Wala sa mga pagkabigong iyon ang naaayos sa pamamagitan ng pagbabago ng isa. Basahin kung aling daloy ang tinitingnan mo bago mag-edit ng panuntunan.

I-verify sa dalawang hangganan

Basahin ang source ng application sa hangganan ng internet, at ang naibalik na destinasyon sa pabalik na bahagi. Sinasabi ng una kung nangyari ang pagsasalin; sinasabi ng pangalawa kung bumalik ang reverse mapping sa tamang client.

Pagkatapos ay subukan ang isang client na gumagamit ng aprubadong split-tunnel path. Hindi kailanman ginagamit ng client na iyon ang internet translation ng router na ito, kaya dapat iba ang gawi nito, at kinukumpirma ng pagkakaiba kung aling path ang tinahak ng trapiko.

Kung magkapareho ang gawi ng dalawang client, hindi ginagawa ng split-tunnel policy ang sinasabi ng disenyo. Ayusin iyon bago magdagdag ng mas maraming panuntunan sa pagsasalin, dahil ang panuntunang isinulat para sa path na hindi ginagamit ay nagtatago ng tunay na problema.