Ali naj uporabite SNAT pri posredovanju vrat v podomrežje VPN?

Posredovanje vrat na gostitelja, ki stoji za lastnim odjemalcem VPN usmerjevalnika, spodleti tako, da je videti kot težava požarnega zidu, ker zahteva očitno prispe. Storitev zabeleži povezavo, odjemalec čaka in nič se ne vrne. Prevod cilja je opravil svoje delo; povratni paket je del, ki je izginil. Eno selektivno pravilo izvornega NAT na usmerjevalniku to popravi, zanimivi del pa je odločiti, kako ozko je lahko to pravilo.

Zakaj odgovor ubere drugo pot

Posredovanje vrat prepiše, kam gre paket, nikoli od kod je prišel. Naslov internetnega odjemalca ostane v polju vira vso pot skozi tunel, zato oddaljena storitev vidi neznanca in odgovori na edini način, ki ga pozna: prek svojih privzetih vrat. Ta vrata so koncentrator VPN na drugi strani, ki nima poti nazaj na poljuben javni naslov.

Oglejte si zajem na vmesniku tunela in asimetrija je očitna: paketi zahteve ven, nič noter. Veriga posredovanja je dovolila tok in tunel ga je prenesel, zato se zavrženje zgodi po tem, ko je oddaljeni gostitelj že izbral povratno pot.

Pravilo vira, dovolj ozko za zaupanje

Naredite usmerjevalnik vir, na katerega odgovarja oddaljeni gostitelj. V tej postavitvi je naslov WAN 203.0.113.24, LAN je 192.168.88.0/24, naslov tunela usmerjevalnika je 172.20.5.1, storitev pa odgovarja na 172.20.5.40:8443. Pravilo spodaj se ujema s paketom po prevodu cilja, zato navaja prevedeni naslov in ne javnega. Nič v njem ni odvisno od naslova odjemalca, in prav to je bistvo.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Vsako ujemanje v tej vrstici obstaja zato, da prepis ostane lokalen za eno storitev na enem tunelu. Odstranite vmesnik ali vrata in prepisujete več prometa, kot ga težava zahteva, in tako se ciljni popravek spremeni v uganko za naslednjo osebo.

Kdaj je splošna maska poštena izbira

Če usmerjevalnik posreduje veliko storitev v isto podomrežje VPN, pravilo na storitev postane seznam, ki ga nihče ne vzdržuje. Maskiranje vsega, kar zapusti vmesnik tunela, je preprostejše in predvidljivejše, za ceno skrivanja prvotnega odjemalca pred vsakim gostiteljem na drugi strani. Izberite to, ko se tamkajšnji dnevniki ne uporabljajo za pripisovanje; ozko pravilo obdržite, ko se.

Obe možnosti tudi spodletita drugače. Manjkajoče ozko pravilo pokvari eno storitev; široka maska, ki se ujema s preveč, lahko tiho prepiše promet, ki je že deloval, vključno z lastnimi odhodnimi povezavami usmerjevalnika.

Pred objavo preverite števce

Pravila, ki se nikoli ne ujemajo, so videti enaka kot pravila, ki delujejo, dokler ne preštejete paketov. Znova preberite tabelo s števci bajtov, preden se poveže kateri koli odjemalec, nato se povežite iz omrežja, ki ni LAN, in jo preberite znova. Dve branji sta tisto, kar domnevo spremeni v dejstvo. Posredovanje objavite šele po tem, ko se drugo premakne.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Ničelni števec na pravilu vira po resnični povezavi pomeni, da je ujemanje napačno, običajno zato, ker se cilj ali vrata ne ujemata s paketom po prevodu. Če števec narašča, a odjemalec še vedno pade v časovno omejitev, je povratna pot popravljena in odgovor zavrže nekaj drugega, zato nato poglejte politiko posredovanja na oddaljeni strani. Dostop z zanko od znotraj LAN je ločena težava in potrebuje svoje pravilo, ne širše različice tega.