OpenVPN-klienten når serveren, men ikke LAN-vertene: sjekkliste

Klienten sier tilkoblet, tunneladressen svarer på ping, og ingenting på kontorets LAN svarer. Jeg ser dette etter nesten hver klientoppgradering, og den første innskytelsen er å åpne brannmuren, som vanligvis er feil trekk: tunnelen er i orden, og bruddet er på ett av tre hopp pakken må krysse. Gå veien i den rekkefølgen pakken tar den, først klientens rute, så videresendingen på serveren, så turen tilbake, og du finner feilens eier på et par minutter.

Trinn én: se på klientens rutingsbeslutning

Før du rører serveren, bevis at klienten sender pakken inn i tunnelen. Spør kjernen hvilket grensesnitt den ville brukt for én bestemt LAN-vert, i stedet for å lese hele tabellen:

ip route get 192.168.50.10

Hvis svaret nevner den fysiske adapteren din og kontorets gateway, kan ingen endring på serversiden hjelpe. OpenVPN deler bare ut ruter når serveren skyver dem, så se etter push "route 192.168.50.0 255.255.255.0" i serverkonfigurasjonen, og koble klienten til på nytt etterpå. De fleste klienter bruker skyvede ruter ved tilkobling, ikke når du laster profilen på nytt.

På Windows har det samme spørsmålet en annen kommando. Find-NetRoute -RemoteIPAddress 192.168.50.10 skriver ut grensesnittet og neste hopp som stakken ville velge, og route print -4 viser om det skyvede prefikset i det hele tatt finnes.

Trinn to: bekreft at serveren vil videresende pakken

Hvis klientens rute er riktig, når pakken serveren, og serveren må godta å videresende den. Kjernebryteren er den første porten, og sysctl net.ipv4.ip_forward må returnere 1. Å sette den med echo 1 > /proc/sys/net/ipv4/ip_forward virker til neste omstart, og det er nettopp derfor den samme klagen kommer tilbake uker senere.

Skriv det ned et sted som overlever en omstart:

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

Den andre porten er filtertabellen. En vert med Docker installert har ofte en FORWARD-policy på DROP, og tunnelen arver den avgjørelsen. iptables -L FORWARD -v -n viser både policyen og pakketellerne; hvis policyen er DROP, trenger videresendingen en uttrykkelig tillatelse for retningen tunnel til LAN og en for svaret.

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

Følg med på begge sider av serveren samtidig. Ta opp på tunnelen og på LAN-grensesnittet, filtrert til én klient og én vert slik at utdataene forblir lesbare:

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

Forespørsler som dukker opp på tun0 og igjen på eth0 med en kilde på 10.8.0.x, etterfulgt av stillhet, betyr at pakken kom frem og svaret gikk et annet sted. LAN-verten svarer standardgatewayen sin, den gatewayen har ingen rute for VPN-bassenget, og svaret dør på LAN-ruteren. Å pinge LAN-verten fra serveren beviser ingenting om denne veien, fordi den trafikken aldri krysser tunnelen.

Trinn fire: velg mellom oversettelse og en returrute

To reparasjoner lukker hullet, og valget har konsekvenser utover om ping virker. Kildeoversettelse gjør serveren til den tilsynelatende avsenderen:

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

Begrens regelen til bassenget og LAN-grensesnittet, og gjør den så permanent, ellers fjerner neste brannmurinnlasting stille rettelsen din. Prisen er identitet: hver klient ser ut som VPN-serveren i LAN-logger og tilgangsregler, og per-client policy becomes guesswork.

En statisk rute for 10.8.0.0/24 på LAN-ruteren, som peker på VPN-serveren, holder klientadressene synlige og er det bedre langsiktige svaret når den ruteren er din. Mange steder kjører begge en stund, NAT for den umiddelbare reparasjonen og ruten når brannmurpolicyen er skrevet. Hvis serveren er en nettsted-til-nettsted-peer i stedet for et basseng, trenger serversiden også en iroute for det eksterne subnettet, ellers finnes peer-ruten, men klienttrafikk blir aldri knyttet til den.

Trinn fem: verifiser fra klienten og noter hva som endret seg

Lukk sløyfen fra klienten, ikke fra serveren. Koble til en ekte tjeneste på LAN-verten, og bekreft deretter at oversettelsestellerne har flyttet seg med iptables -t nat -L POSTROUTING -v -n, fordi en regel med null pakker er en regel som aldri har matchet. conntrack -L -s 10.8.0.5 viser flyten og tilstanden dens når du trenger bevis for at returretningen spores.

Legg igjen et notat i serverkonfigurasjonen: hvilket subnett, hvilket grensesnitt, hvilken regel, og om LAN-ruteren har en rute tilbake. Neste gang en klientoppgradering sletter en skyvet rute, gjør det notatet en brannslokkingsøkt om til en rettelse på én linje.