OpenVPN klijent doseže server, ali ne i LAN hostove: kontrolna lista

Klijent kaže da je povezan, adresa tunela odgovara na ping, a ništa na uredskoj LAN mreži ne reaguje. Ovo vidim nakon gotovo svakog ažuriranja klijenta, a prvi instinkt je otvoriti firewall, što je obično pogrešan potez: tunel je ispravan, a prekid je na jednom od tri skoka koja paket mora proći. Prođite putem onim redom kojim paket ide, prvo klijentska ruta, zatim prosljeđivanje na serveru, zatim povratno putovanje, i vlasnika kvara ćete pronaći za nekoliko minuta.

Prvi korak: gledajte odluku klijenta o rutiranju

Prije nego dirnete server, dokažite da klijent šalje paket u tunel. Pitajte kernel koji bi interfejs koristio za jednog konkretnog LAN hosta, umjesto da čitate cijelu tablicu:

ip route get 192.168.50.10

Ako odgovor navodi vaš fizički adapter i uredski gateway, nikakva promjena na strani servera ne može pomoći. OpenVPN dijeli rute samo kada ih server gura, zato potražite push "route 192.168.50.0 255.255.255.0" u konfiguraciji servera i nakon toga ponovo povežite klijent. Većina klijenata primjenjuje gurnute rute u trenutku povezivanja, a ne kada ponovo učitate profil.

Na Windowsu isto pitanje ima drugu komandu. Find-NetRoute -RemoteIPAddress 192.168.50.10 ispisuje interfejs i sljedeći skok koji bi stog odabrao, a route print -4 pokazuje postoji li gurnuti prefiks uopće.

Drugi korak: potvrdite da će server proslijediti paket

Ako je klijentska ruta ispravna, paket stiže do servera i server mora pristati da ga proslijedi. Kernel prekidač je prva kapija, a sysctl net.ipv4.ip_forward mora vratiti 1. Postavljanje pomoću echo 1 > /proc/sys/net/ipv4/ip_forward radi do sljedećeg restarta, i upravo zato se ista žalba vraća sedmicama kasnije.

Zapišite to negdje gdje preživljava restart:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Druga kapija je tabela filtera. Host s instaliranim Dockerom često nosi FORWARD politiku DROP, a tunel nasljeđuje tu odluku. iptables -L FORWARD -v -n prikazuje i politiku i brojače paketa; ako je politika DROP, prosljeđivanje treba izričito dopuštenje za smjer od tunela prema LAN-u i još jedno za odgovor.

Treći korak: pratite paket na LAN i tražite odgovor

Gledajte obje strane servera istovremeno. Snimajte na tunelu i na LAN interfejsu, filtrirano na jednog klijenta i jedan host da ispis ostane čitljiv:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Zahtjevi koji se pojave na tun0 i ponovo na eth0 s izvorom 10.8.0.x, nakon čega slijedi tišina, znače da je paket stigao, a odgovor je otišao negdje drugdje. LAN host odgovara svom zadanom gatewayu, taj gateway nema rutu za VPN pool, i odgovor umire na LAN ruteru. Pingovanje LAN hosta sa servera ne dokazuje ništa o tom putu, jer taj promet nikada ne prelazi tunel.

Četvrti korak: odaberite između translacije i povratne rute

Dva popravka zatvaraju rupu, a izbor ima posljedice i izvan toga radi li ping. Translacija izvora čini server prividnim pošiljaocem:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Ograničite pravilo na pool i LAN interfejs, pa ga učinite trajnim, inače sljedeće ponovno učitavanje firewalla tiho uklanja vaš popravak. Cijena je identitet: svaki klijent izgleda kao VPN server u LAN zapisima i pravilima pristupa, i per-client policy becomes guesswork.

Statička ruta za 10.8.0.0/24 na LAN ruteru, usmjerena na VPN server, održava adrese klijenata vidljivima i bolji je dugoročni odgovor kada je taj ruter vaš. Mnoge lokacije neko vrijeme drže oboje, NAT za trenutni popravak i rutu nakon što se napiše firewall politika. Ako je server site-to-site peer, a ne pool, strana servera također treba iroute za udaljenu podmrežu, inače peer ruta postoji, ali promet klijenata nikada se ne povezuje s njom.

Peti korak: provjerite s klijenta i zapišite šta se promijenilo

Zatvorite petlju s klijenta, ne sa servera. Povežite se na stvarnu uslugu na LAN hostu, pa potvrdite da su se brojači translacije pomjerili pomoću iptables -t nat -L POSTROUTING -v -n, jer pravilo s nula paketa je pravilo koje se nikada nije poklopilo. conntrack -L -s 10.8.0.5 pokazuje tok i njegovo stanje kada vam treba dokaz da se povratni smjer prati.

Ostavite bilješku u konfiguraciji servera: koja podmreža, koji interfejs, koje pravilo i nosi li LAN ruter povratnu rutu. Sljedeći put kada ažuriranje klijenta obriše gurnutu rutu, ta bilješka pretvara sesiju gašenja požara u popravak u jednom redu.