Rutirani VPN klijent dosegne server, ali ne i LAN hostove

Tunel se podigne, klijent pinga VPN server, a dijeljeni folder na mašini jedan skok dalje nikad ne odgovori. Ništa u konfiguraciji klijenta to ne objašnjava, jer je zahtjev zaista napustio klijent i zaista stigao. Ono što nije uspjelo je povratno putovanje, a uređaj koji nije uspio obično je LAN gateway, a ne VPN host. Praćenje paketa odgovora objašnjava cijelu ovu klasu simptoma.

Pratite odgovor, ne zahtjev

VPN server dekriptira paket klijenta i prosljeđuje ga na LAN, a adresa klijenta ostaje u polju izvora. Odredišni host odgovara na tu adresu, i sada njegova vlastita routing tabela odlučuje o svemu. Njegov zadani gateway ne zna ništa o pulu tunela, pa odgovor odlazi prema internet provajderu i biva odbačen negdje na tom putu.

Na klijentu je simptom tihi timeout: nema odbijanja, nema reseta, samo ništa. Pregled dijeljenog foldera se zablokira, ping javlja da nema odgovora, a serverski logovi izgledaju zdravo jer je server odradio svoj posao.

Stavite povratnu rutu tamo gdje hostovi gledaju

Svaki LAN host konsultuje svoj zadani gateway, pa je gateway jedini uređaj koji mora znati gdje se nalazi pul tunela. Dodajte tamo statičku rutu i svaki host naslijedi ispravnu putanju bez diranja.

Ako gateway distribuira vlastitu adresu kao DHCP opciju, distribuirajte rutu na taj način da je nove mašine automatski preuzmu. Inače ruta živi u jednoj konfiguracijskoj datoteci i nestaje pri sljedećoj ponovnoj izgradnji.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Zašto izgleda da Source NAT popravlja stvar

Maskiranje pula klijenata iza adrese VPN servera uklanja problem uklanjanjem adrese klijenta iz paketa. Odgovori se tada vraćaju na server, koji već zna kako do tunela, i sve radi. Cijena je da interni hostovi više ne mogu vidjeti ko je klijent, i svaka veza izgleda kao da dolazi s jedne mašine.

Ta razmjena je ponekad ispravna, na primjer kada se uređaju dobavljača ne može dati statička ruta. Napravite pravilo ne šire od trenutnog pula, jer pravilo napisano za /24 prestaje da se poklapa onog dana kada se pul prenumeriše u /16, a prvi znak je grupa novih klijenata koji se povežu i ne dosegnu ništa.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Cloud putanja zahtijeva tri postavke

U VPC-u se ista praznina vraća u drugom obliku, jer subnet uopšte nema rutu za raspon klijenata. Routing tabela treba unos za pul tunela koji cilja mrežno sučelje instance, a sučelje treba isključenu provjeru izvora i odredišta kako bi platforma prihvatila pakete čiji izvor nije njena vlastita adresa. Sigurnosne grupe i mrežni ACL-i također moraju propuštati pul u oba smjera.

Svaki propust proizvodi poseban djelimični kvar. Preskočite unos u routing tabeli i privatne instance odgovaraju u subnet koji ne može prenijeti odgovor natrag u pul. S uključenom provjerom platforma odbacuje odgovor nakon što ga je instanca već poslala. Bez pravila sigurnosne grupe sam zahtjev nikad ne stigne, a klijent vidi timeout jedan sloj ranije.

Izvršite provjere u ovom redoslijedu

Potvrdite prosljeđivanje i politiku filtriranja prije nego okrivite routing, jer host koji neće prosljeđivati pada na isti tihi način. Zatim pročitajte efektivnu postavku obrnute putanje na sučelju koje nosi tunel, jer strogi filter može odbaciti odgovore koji dolaze iz neočekivanog smjera.

Završite snimkom na LAN hostu dok ga klijent pinga. Zahtjev koji stigne bez odgovarajućeg odgovora dokazuje povratnu putanju, a zahtjev koji nikad ne stigne vraća krivnju na server ili tunel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Provjera izvora i odredišta dokumentovana je u vodiču za elastična mrežna sučelja. Postavite je na sučelje koje stvarno nosi promet tunela, ne na nepovezani adapter priključen na istu instancu.