Pagkatapos ng pagbabago ng IP ng server, pinapangalanan pa rin ng SNAT rule ang luma

Lumipat ang server sa bagong address, kumokonekta pa rin ang mga kliyente, at wala sa kanilang ipinapadala ang nakakarating sa internet. Ang paghihiwalay na iyon ang palatandaan: ang nakikinig na socket at ang port forwarding ay nakaligtas sa paglipat, kaya bumangon ang tunnel, samantalang ang pagsasalin ng pinagmulan na inilalapat sa mga ipinasang packet ay pinapangalanan pa rin ang isang address na hindi na pag-aari ng host. Ang mga sagot sa mga naisulat na packet na iyon ay pumupunta sa isang makina na wala na.

Nabigo ang pagkonekta at pagpapasa sa magkaibang lugar

Nakadepende ang pagtatatag sa endpoint na alam na ng mga kliyente: ang pampublikong address, ang port forwarding sa harap nito at ang tagapakinig sa loob. Ang ipinasang trapiko ay nakadepende sa ikalawang desisyon na ginagawa pagkatapos pumasok ang packet sa tunnel, kapag isinusulat muli ng host ang pinagmulan nito upang mahanap ng mga sagot ang daan pabalik.

Ang pagbabago ng address ay sumisira lamang sa ikalawang desisyon, at dahil doon binabasa ang sintomas bilang "konektado ngunit walang internet". Ipinaliliwanag din nito kung bakit mukhang malusog ang karaniwang pagsusuri sa panig ng kliyente: natatapos ang pagkamay-kamay, nakakatanggap ng address ang kliyente, at maging ang ping sa tunnel address ng server ay maaaring sumagot. Nasaad ang mga oras sa kliyente para sa sira na naninirahan sa kabilang panig, kaya ang talahanayan ng mga panuntunan ang unang lugar na titingnan.

Basahin ang panuntunan at ang mga counter nito bago mag-edit

Ilista ang mga panuntunan ng pagsasalin kasama ang mga counter at ihambing ang naka-configure na pinagmulan sa mga address na aktwal na hawak ng host. Ang panuntunang naisulat muli sa patay na address ay karaniwang nagpapakita ng trapiko sa papasok na daan, dahil nararating ito ng mga packet at naisasalin, at wala sa pabalik na daan.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Suriin ang tatlong field habang naroon ka: ang pool sa pagtutugma ng pinagmulan, ang exit interface kung may pinapangalanan ang panuntunan, at ang pagbubukod na pumipigil sa trapiko sa pagitan ng mga tunnel na maisulat muli. Madaling mawala ang pagbubukod na iyon sa pag-edit, at kapag nawala ito ay mukhang gumagana ang trapiko sa pagitan ng mga kapantay habang ang mga sagot nito ay dumadaan sa kakaibang landas.

Kung ang mga counter ay natigil sa zero, hindi kailanman nararating ng mga packet ang panuntunang ito at ang address ay hindi ang kasalukuyang problema. Maghanap ng karibal na panuntunan nang mas maaga sa chain, na nangyayari kapag may nagdagdag ng kapalit sa halip na i-edit ang orihinal. Ihambing ang mga numero ng panuntunan sa output na naitala mo isang minuto ang nakalipas. Ang pagkakasunod-sunod ay bahagi ng configuration, hindi kosmetikong detalye.

Palitan ang pinagmulan, o tigilan ang pagpapangalan nito

Kapag may matatag na address ang host, palitan ang panuntunan sa lugar nito sa halip na magdagdag ng isa pa. Ang pagpapalit ayon sa numero ng panuntunan ay nagpapanatili ng pagkakasunod-sunod na pinagkakatiwalaan ng natitirang chain.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Kapag ang address ay itinatalaga nang pabago-bago, huwag magpangalan ng anumang pinagmulan at hayaang piliin ng kernel ang kasalukuyan mula sa exit interface. Ang variant na iyon ay nakakaligtas sa susunod na paglipat nang walang pag-edit, kapalit ng pagtatago kung aling address ang ginamit.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Kumpirmahin na ang IPv4 forwarding ay naka-enable pa rin sa pamamagitan ng pinamamahalaang configuration, pagkatapos gawing permanente ang panuntunan gamit ang sariling mekanismo ng distribution. Ang pagbabagong ginawa lamang sa tumatakbong kernel ay bumabalik sa susunod na reboot, kadalasan sa isang maintenance window na walang nag-uugnay sa pagbabago.

Dalawang paraan upang mali ang pagpapalit

Ang pagsasalin ng pool sa tunnel address ng server sa halip na sa LAN address nito ay nagpapadala ng mga sagot nang direkta pabalik sa tunnel, kung saan iruruta ang mga ito patungo sa kliyenteng hindi kailanman humiling ng mga ito. Natigil ang koneksyon sa paraang mukhang routing loop, dahil ito nga ay loop.

Ang pagsasalansan ng ikalawang pagsasalin sa ibabaw ng luma ay ang isa pang pagkakamali. Ang unang tugmang panuntunan ang nananalo, kaya patuloy na hinahawakan ng lumang entry ang mga packet hanggang ito ay burahin, at ang mga counter ng bagong panuntunan ay nananatiling zero habang lahat ay sinisisi ang kapalit. Burahin ang duplicate bago magdagdag ng anumang bago. Pagkatapos basahin muli ang listahan at kumpirmahin na eksaktong isang pagsasalin ang tumutugma sa pool.

Kung ang tunnel ay nagdadala rin ng IPv6, ulitin ang buong pagsusuri sa kabilang stack. Ang default na ruta ng IPv6 na walang pagsasalin at walang nirurutang prefix ay nabigo nang tahimik din, at madaling makalimutan dahil ang lahat sa itaas nito ay mukhang pareho.

Ang mga papasok na serbisyo ay nangangailangan ng kabaligtarang pagsasalin

Ang serbisyo sa isang kliyente ng VPN na dapat maabot mula sa labas ay nangangailangan ng pagsasalin ng destinasyon, hindi ng pinagmulan: ang pampublikong port ay isinusulat muli sa tunnel address ng kliyente bago ito pumasok. Ang daan ng pagpapasa ay nangangailangan ng tahasang panuntunan na nagpapahintulot sa trapikong iyon.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Huwag kailanman isalin ang port na nagdadala ng tunnel mismo, dahil ang pagsusulat muli na iyon ay pumipigil sa koneksyong nagpapanatili sa serbisyo na maabot. Panatilihin ang tunnel port nang lubos na labas sa mga panuntunan ng destinasyon. Sa huli, i-verify mula sa dalawang dulo: mga counter sa bagong panuntunan, isang maikling capture sa tunnel device, at isang kahilingan sa isang address sa loob ng tunnel bago subukan ang pampubliko.