OpenVPN-klient når serveren, men ikke LAN-værterne: tjekliste

Klienten siger forbundet, tunneladressen svarer på en ping, og intet på kontorets LAN reagerer. Jeg ser dette efter næsten hver klientopgradering, og den første indskydelse er at åbne firewallen, hvilket som regel er det forkerte træk: tunnelen er i orden, og bruddet er på et af tre hop, som pakken skal passere. Gå vejen i den rækkefølge, pakken tager den, først klientens rute, så videresendelsen på serveren, så turen tilbage, og du finder fejlens ejer på et par minutter.

Trin et: se klientens routingbeslutning

Før du rører serveren, skal du bevise, at klienten sender pakken ind i tunnelen. Spørg kernen, hvilket interface den ville bruge til en bestemt LAN-vært, i stedet for at læse hele tabellen:

ip route get 192.168.50.10

Hvis svaret nævner din fysiske adapter og kontorets gateway, kan ingen ændring på serversiden hjælpe. OpenVPN uddeler kun ruter, når serveren skubber dem, så se efter push "route 192.168.50.0 255.255.255.0" i serverkonfigurationen, og genopret klienten bagefter. De fleste klienter anvender skubbede ruter ved forbindelse, ikke når du genindlæser profilen.

På Windows har det samme spørgsmål en anden kommando. Find-NetRoute -RemoteIPAddress 192.168.50.10 udskriver det interface og det næste hop, som stakken ville vælge, og route print -4 viser, om det skubbede præfiks overhovedet findes.

Trin to: bekræft, at serveren vil videresende pakken

Hvis klientens rute er rigtig, når pakken serveren, og serveren skal acceptere at videresende den. Kerneskifteren er den første port, og sysctl net.ipv4.ip_forward skal returnere 1. At sætte den med echo 1 > /proc/sys/net/ipv4/ip_forward virker indtil næste genstart, og det er netop derfor, den samme klage vender tilbage uger senere.

Skriv det et sted, der overlever en genstart:

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

Den anden port er filtertabellen. En vært med Docker installeret har ofte en FORWARD-politik på DROP, og tunnelen arver den beslutning. iptables -L FORWARD -v -n viser både politikken og pakketællerne; er politikken DROP, kræver videresendelse en udtrykkelig tilladelse for retningen tunnel til LAN og en for svaret.

Trin tre: følg pakken ud på LAN’et og led efter svaret

Overvåg begge sider af serveren på én gang. Optag på tunnelen og på LAN-interfacet, filtreret til én klient og én vært, så outputtet forbliver læsbart:

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

Forespørgsler, der dukker op på tun0 og igen på eth0 med en kilde på 10.8.0.x, efterfulgt af tavshed, betyder, at pakken ankom, og svaret gik et andet sted hen. LAN-værten svarer sin standardgateway, den gateway har ingen rute til VPN-puljen, og svaret dør på LAN-routeren. At pinge LAN-værten fra serveren beviser intet om denne vej, for den trafik krydser aldrig tunnelen.

Trin fire: vælg mellem oversættelse og en returrute

To reparationer lukker hullet, og valget har konsekvenser ud over, om ping virker. Kildeoversættelse gør serveren til den tilsyneladende afsender:

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

Afgræns reglen til puljen og LAN-interfacet, og gør den så permanent, ellers fjerner den næste firewall-genindlæsning stille din rettelse. Prisen er identitet: hver klient ser ud som VPN-serveren i LAN-logs og adgangsregler, og per-client policy becomes guesswork.

En statisk rute til 10.8.0.0/24 på LAN-routeren, der peger på VPN-serveren, holder klientadresser synlige og er det bedre langsigtede svar, når den router er din. Mange steder kører begge dele et stykke tid, NAT til den øjeblikkelige reparation og ruten, når firewallpolitikken er skrevet. Hvis serveren er en site-til-site-peer i stedet for en pulje, har serversiden også brug for en iroute til det fjernede subnet, ellers findes peer-ruten, men klienttrafik bliver aldrig knyttet til den.

Trin fem: verificér fra klienten, og notér hvad der ændrede sig

Luk kredsen fra klienten, ikke fra serveren. Forbind til en rigtig tjeneste på LAN-værten, og bekræft så, at oversættelsestællerne har flyttet sig med iptables -t nat -L POSTROUTING -v -n, for en regel med nul pakker er en regel, der aldrig har matchet. conntrack -L -s 10.8.0.5 viser flowet og dets tilstand, når du har brug for bevis for, at returretningen spores.

Efterlad en note i serverkonfigurationen: hvilket subnet, hvilket interface, hvilken regel, og om LAN-routeren bærer en rute tilbage. Næste gang en klientopgradering rydder en skubbet rute, forvandler den note en brandslukningssession til en rettelse på én linje.