OpenVPN-klienten når serveren, men ikkje LAN-vertane: sjekkliste

Klienten seier tilkopla, tunneladressa svarar på ping, og ingenting på kontorets LAN svarar. Eg ser dette etter nesten kvar klientoppgradering, og den første innskytelsen er å opne brannmuren, som vanlegvis er feil trekk: tunnelen er i orden, og brotet er på eitt av tre hopp pakken må krysse. Gå vegen i den rekkjefølgja pakken tar han, først klientruta, så vidaresendinga på serveren, så turen tilbake, og du finn eigaren av feilen på eit par minutt.

Trinn éin: sjå på rutingsavgjerda til klienten

Før du rører serveren, prov at klienten sender pakken inn i tunnelen. Spør kjernen kva grensesnitt han ville bruke for éin bestemt LAN-vert, i staden for å lese heile tabellen:

ip route get 192.168.50.10

Viss svaret nemner den fysiske adapteren din og kontorets gateway, kan inga endring på serversida hjelpe. OpenVPN deler berre ut ruter når serveren skuvar dei, så sjå etter push "route 192.168.50.0 255.255.255.0" i serverkonfigurasjonen, og kople klienten til på nytt etterpå. Dei fleste klientar brukar skyvde ruter ved tilkopling, ikkje når du lastar profilen på nytt.

På Windows har det same spørsmålet ein annan kommando. Find-NetRoute -RemoteIPAddress 192.168.50.10 skriv ut grensesnittet og neste hopp som stakken ville velje, og route print -4 viser om det skyvde prefikset i det heile finst.

Trinn to: stadfest at serveren vil videresende pakken

Viss klientruta er riktig, når pakken serveren, og serveren må godta å videresende han. Kjernebrytaren er den første porten, og sysctl net.ipv4.ip_forward må returnere 1. Å setje han med echo 1 > /proc/sys/net/ipv4/ip_forward verkar til neste omstart, og det er nettopp derfor den same klaga kjem tilbake veker seinare.

Skriv det ned ein stad som overlever ein omstart:

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

Den andre porten er filtertabellen. Ein vert med Docker installert har ofte ein FORWARD-policy på DROP, og tunnelen arvar den avgjerda. iptables -L FORWARD -v -n viser både policyen og pakketeljarane; er policyen DROP, treng videresendinga ei uttrykkeleg løyve for retninga tunnel til LAN og éi for svaret.

Trinn tre: følg pakken ut på LAN-et og sjå etter svaret

Følg med på begge sider av serveren samstundes. Ta opp på tunnelen og på LAN-grensesnittet, filtrert til éin klient og éin vert slik at utdataa blir lesbare:

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

Førespurnader som dukkar opp på tun0 og igjen på eth0 med ei kjelde på 10.8.0.x, etterfølgd av stillheit, betyr at pakken kom fram og svaret gjekk ein annan stad. LAN-verten svarar standardgatewayen sin, den gatewayen har inga rute for VPN-bassenget, og svaret døyr på LAN-rutaren. Å pinge LAN-verten frå serveren provar ingenting om denne vegen, fordi den trafikken aldri kryssar tunnelen.

Trinn fire: vel mellom omsetjing og ei returrute

To reparasjonar lukkar holet, og valet har konsekvensar utover om ping verkar. Kjeldeomsetjing gjer serveren til den tilsynelatande avsendaren:

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

Avgrens regelen til bassenget og LAN-grensesnittet, og gjer han så permanent, elles fjernar neste brannmurinnlasting stille rettinga di. Prisen er identitet: kvar klient ser ut som VPN-serveren i LAN-loggar og tilgangsreglar, og per-client policy becomes guesswork.

Ei statisk rute for 10.8.0.0/24 på LAN-rutaren, som peiker på VPN-serveren, held klientadressene synlege og er det betre langsiktige svaret når den rutaren er din. Mange stader køyrer begge ei stund, NAT for den umiddelbare reparasjonen og ruta når brannmurpolicyen er skriven. Viss serveren er ein nettstad-til-nettstad-peer i staden for eit basseng, treng serversida også ein iroute for det eksterne subnettet, elles finst peer-ruta, men klienttrafikk blir aldri knytt til henne.

Trinn fem: verifiser frå klienten og noter kva som endra seg

Lukk sløyfa frå klienten, ikkje frå serveren. Kople til ein ekte teneste på LAN-verten, og stadfest då at omsetjingsteljarane har flytta seg med iptables -t nat -L POSTROUTING -v -n, fordi ein regel med null pakkar er ein regel som aldri har matcha. conntrack -L -s 10.8.0.5 viser flyten og tilstanden hans når du treng prov for at returretninga blir spora.

Legg igjen eit notat i serverkonfigurasjonen: kva subnett, kva grensesnitt, kva regel, og om LAN-rutaren har ei rute tilbake. Neste gong ein klientoppgradering slettar ei skyvd rute, gjer det notatet ein brannsløkkingsøkt om til ei retting på éi linje.