Odjemalec OpenVPN doseže strežnik, ne pa gostiteljev v LAN: kontrolni seznam

Odjemalec pravi, da je povezan, naslov predora odgovarja na ping, v pisarniškem LAN pa se nič ne odziva. To vidim po skoraj vsaki posodobitvi odjemalca, prvi impulz pa je odpreti požarni zid, kar je običajno napačna poteza: predor je v redu, prekinitev pa je na enem od treh skokov, ki jih mora paket prestati. Prehodite pot v vrstnem redu, v katerem jo opravi paket, najprej pot odjemalca, nato posredovanje na strežniku, nato vrnitev, in krivca za napako boste našli v nekaj minutah.

Prvi korak: opazujte odločitev odjemalca o usmerjanju

Preden se dotaknete strežnika, dokažite, da odjemalec pošilja paket v predor. Vprašajte jedro, kateri vmesnik bi uporabilo za enega konkretnega gostitelja v LAN, namesto da berete celotno tabelo:

ip route get 192.168.50.10

Če odgovor navaja vaš fizični vmesnik in pisarniška vrata, nobena sprememba na strani strežnika ne more pomagati. OpenVPN deli poti le, ko jih strežnik potisne, zato poiščite push "route 192.168.50.0 255.255.255.0" v konfiguraciji strežnika in nato odjemalca znova povežite. Večina odjemalcev uporabi potisnjene poti ob povezavi, ne ko znova naložite profil.

V sistemu Windows ima isto vprašanje drug ukaz. Find-NetRoute -RemoteIPAddress 192.168.50.10 izpiše vmesnik in naslednji skok, ki bi ga izbral sklad, route print -4 pa pokaže, ali potisnjena predpona sploh obstaja.

Drugi korak: potrdite, da bo strežnik paket posredoval

Če je pot odjemalca pravilna, paket doseže strežnik in strežnik mora privoliti v posredovanje. Stikalo jedra so prva vrata in sysctl net.ipv4.ip_forward mora vrniti 1. Nastavitev z echo 1 > /proc/sys/net/ipv4/ip_forward deluje do naslednjega ponovnega zagona, in prav zato se ista pritožba vrne tedne pozneje.

Zapišite si to nekam, kar preživi ponovni zagon:

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

Druga vrata so tabela filtrov. Gostitelj z nameščenim Dockerjem ima pogosto politiko FORWARD nastavljeno na DROP, predor pa to odločitev podeduje. iptables -L FORWARD -v -n prikaže politiko in števce paketov; če je politika DROP, posredovanje potrebuje izrecno dovoljenje za smer iz predora v LAN in še eno za odgovor.

Tretji korak: sledite paketu v LAN in poiščite odgovor

Opazujte obe strani strežnika hkrati. Zajemajte na predoru in na vmesniku LAN, filtrirano na enega odjemalca in enega gostitelja, da izpis ostane berljiv:

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

Zahteve, ki se pojavijo na tun0 in znova na eth0 z virom 10.8.0.x, ki jim sledi tišina, pomenijo, da je paket prispel in je odgovor odšel drugam. Gostitelj v LAN odgovori svoji privzeti prehodni točki, ta prehodna točka nima poti za zbirko VPN in odgovor umre na usmerjevalniku LAN. Pinganje gostitelja v LAN s strežnika ne dokaže ničesar o tej poti, ker ta promet nikoli ne prestopi predora.

Četrti korak: izberite med pretvorbo in povratno potjo

Dve popravili zapreta luknjo in izbira ima posledice onkraj tega, ali ping deluje. Pretvorba vira naredi strežnik navideznega pošiljatelja:

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

Omejite pravilo na zbirko in vmesnik LAN, nato ga naredite trajnega, sicer bo naslednje nalaganje požarnega zidu tiho odstranilo vaš popravek. Cena je identiteta: vsak odjemalec je v dnevnikih LAN in v pravilih dostopa videti kot strežnik VPN, in per-client policy becomes guesswork.

Statična pot za 10.8.0.0/24 na usmerjevalniku LAN, ki kaže na strežnik VPN, ohranja naslove odjemalcev vidne in je boljši dolgoročni odgovor, ko je ta usmerjevalnik vaš. Veliko mest nekaj časa poganja oboje, NAT za takojšnje popravilo in pot, ko je politika požarnega zidu napisana. Če je strežnik sopotnik od mesta do mesta in ne zbirka, tudi stran strežnika potrebuje iroute za oddaljeno podomrežje, sicer pot sopotnika obstaja, a promet odjemalcev se z njo nikoli ne poveže.

Peti korak: preverite z odjemalca in zapišite, kaj se je spremenilo

Zanko zaprite z odjemalca, ne s strežnika. Povežite se z resnično storitvijo na gostitelju v LAN, nato potrdite, da so se števci pretvorbe premaknili s iptables -t nat -L POSTROUTING -v -n, ker pravilo brez paketov je pravilo, ki se nikoli ni ujemalo. conntrack -L -s 10.8.0.5 prikaže tok in njegovo stanje, ko potrebujete dokaz, da se povratna smer spremlja.

V konfiguraciji strežnika pustite opombo: katera podmreža, kateri vmesnik, katero pravilo in ali ima usmerjevalnik LAN povratno pot. Ko bo naslednja posodobitev odjemalca izbrisala potisnjeno pot, bo ta opomba gašenje požara spremenila v popravek ene vrstice.