OpenVPN klijent doseže poslužitelj, ali ne i LAN hostove: kontrolni popis

Klijent kaže da je povezan, adresa tunela odgovara na ping, a ništa na uredskoj LAN mreži ne reagira. Ovo vidim nakon gotovo svakog ažuriranja klijenta, a prvi instinkt je otvoriti vatrozid, š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 poslužitelju, zatim povratno putovanje, i vlasnika kvara pronaći ćete za nekoliko minuta.

Prvi korak: promatrajte odluku klijenta o usmjeravanju

Prije nego dotaknete poslužitelj, 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 poslužitelja ne može pomoći. OpenVPN dijeli rute samo kada ih poslužitelj gura, zato potražite push "route 192.168.50.0 255.255.255.0" u konfiguraciji poslužitelja i nakon toga ponovno povežite klijent. Većina klijenata primjenjuje gurnute rute u trenutku povezivanja, a ne kada ponovno učitate profil.

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

Drugi korak: potvrdite da će poslužitelj proslijediti paket

Ako je klijentska ruta ispravna, paket stiže do poslužitelja i poslužitelj 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 tjednima 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 tablica 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

Promatrajte obje strane poslužitelja 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 ponovno 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 usmjerivaču. Pinganje LAN hosta s poslužitelja ne dokazuje ništa o tom putu, jer taj promet nikada ne prelazi tunel.

Četvrti korak: odaberite između prevođenja i povratne rute

Dva popravka zatvaraju rupu, a izbor ima posljedice i izvan toga radi li ping. Prevođenje izvora čini poslužitelj prividnim pošiljateljem:

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 vatrozida tiho uklanja vaš popravak. Cijena je identitet: svaki klijent izgleda kao VPN poslužitelj u LAN zapisima i pravilima pristupa, i per-client policy becomes guesswork.

Statička ruta za 10.8.0.0/24 na LAN usmjerivaču, usmjerena na VPN poslužitelj, održava adrese klijenata vidljivima i bolji je dugoročni odgovor kada je taj usmjerivač vaš. Mnoge lokacije neko vrijeme drže oboje, NAT za trenutni popravak i rutu nakon što se napiše politika vatrozida. Ako je poslužitelj site-to-site peer, a ne pool, strana poslužitelja 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 što se promijenilo

Zatvorite petlju s klijenta, ne s poslužitelja. Povežite se na stvarnu uslugu na LAN hostu, pa potvrdite da su se brojači prevođenja pomaknuli 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 poslužitelja: koja podmreža, koji interfejs, koje pravilo i nosi li LAN usmjerivač 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.