Treba li primijeniti SNAT na prosljeđivanje porta u VPN podmrežu?

Prosljeđivanje porta na host koji stoji iza vlastitog VPN klijenta usmjerivača ne uspijeva na način koji izgleda kao problem vatrozida, jer zahtjev očito stiže. Usluga bilježi vezu, klijent čeka i ništa se ne vraća. Prevođenje odredišta odradilo je svoj posao; povratni paket je dio koji je nestao. Jedno selektivno pravilo izvornog NAT-a na usmjerivaču to popravlja, a zanimljiv dio je odlučiti koliko to pravilo može biti usko.

Zašto odgovor ide drugim putem

Prosljeđivanje porta prepisuje kamo paket ide, nikada odakle je došao. Adresa internetskog klijenta ostaje u polju izvora cijelim putem kroz tunel, pa udaljena usluga vidi stranca i odgovara jedino kako zna: kroz vlastiti zadani pristupnik. Taj pristupnik je VPN koncentrator na drugoj strani, koji nema rutu natrag na proizvoljnu javnu adresu.

Pogledajte snimku na sučelju tunela i asimetrija je očita: paketi zahtjeva izlaze, ništa ne ulazi. Lanac prosljeđivanja dopustio je tok i tunel ga je prenio, pa se odbacivanje događa nakon što je udaljeni host već odabrao povratni put.

Izvorno pravilo dovoljno usko da mu se vjeruje

Učinite usmjerivač izvorom na koji udaljeni host odgovara. U ovom rasporedu WAN adresa je 203.0.113.24, LAN je 192.168.88.0/24, adresa tunela usmjerivača je 172.20.5.1, a usluga odgovara na 172.20.5.40:8443. Pravilo ispod podudara paket nakon prevođenja odredišta, zato imenuje prevedenu adresu, a ne javnu. Ništa u njemu ne ovisi o adresi klijenta i upravo je to poanta.

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

Svako podudaranje u tom retku postoji kako bi prepisivanje ostalo lokalno za jednu uslugu na jednom tunelu. Uklonite sučelje ili port i prepisujete više prometa nego što problem zahtijeva, a tako ciljana popravka postaje misterij za sljedeću osobu.

Kada je sveobuhvatna maskerada pošten izbor

Ako usmjerivač prosljeđuje mnogo usluga u istu VPN podmrežu, pravilo po usluzi postaje popis koji nitko ne održava. Maskiranje svega što napušta sučelje tunela jednostavnije je i predvidljivije, po cijeni skrivanja izvornog klijenta od svakog hosta na drugoj strani. Odaberite to kada se tamošnji zapisi ne koriste za atribuciju; zadržite usko pravilo kada se koriste.

Dvije opcije i ne uspijevaju različito. Nedostajuće usko pravilo kvari jednu uslugu; široka maskerada koja podudara previše može tiho prepisati promet koji je već radio, uključujući vlastite odlazne veze usmjerivača.

Provjerite brojače prije objave

Pravila koja se nikad ne podudaraju izgledaju isto kao pravila koja rade dok ne prebrojite pakete. Pročitajte tablicu ponovno s brojačima bajtova prije nego se bilo koji klijent spoji, zatim se spojite s mreže koja nije LAN i pročitajte je opet. Dva su čitanja ono što nagađanje pretvara u činjenicu. Objavite prosljeđivanje tek nakon što se drugo pomakne.

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

Nulti brojač na izvornom pravilu nakon stvarne veze znači da je podudaranje pogrešno, obično zato što odredište ili port ne odgovaraju paketu nakon prevođenja. Ako brojač raste, ali klijent još uvijek isteče, povratni put je popravljen i nešto drugo odbacuje odgovor, pa sljedeće pogledajte pravila prosljeđivanja na drugoj strani. Pristup kroz ukosnicu iz LAN-a zaseban je problem i treba vlastito pravilo, a ne širu verziju ovoga.