OpenVPN-client bereikt de server maar niet de LAN-hosts: checklist

De client zegt verbonden, het tunneladres antwoordt op een ping, en niets op de kantoor-LAN reageert. Ik zie dit na bijna elke client-upgrade, en de eerste reflex is de firewall openzetten, wat meestal de verkeerde stap is: de tunnel is in orde, en de breuk zit op een van de drie hops die het pakket moet passeren. Loop de route in de volgorde waarin het pakket hem aflegt, eerst de clientroute, dan het doorsturen op de server, dan de terugreis, en je vindt de eigenaar van de fout binnen een paar minuten.

Stap een: kijk naar de routingbeslissing van de client

Voordat je de server aanraakt, bewijs je dat de client het pakket de tunnel in stuurt. Vraag de kernel welke interface hij voor één specifieke LAN-host zou gebruiken, in plaats van de hele tabel te lezen:

ip route get 192.168.50.10

Als het antwoord je fysieke adapter en de kantoorpoort noemt, kan geen wijziging aan de serverkant helpen. OpenVPN deelt alleen routes uit wanneer de server ze pusht, dus zoek push "route 192.168.50.0 255.255.255.0" in de serverconfiguratie en verbind de client daarna opnieuw. De meeste clients passen gepushte routes toe bij het verbinden, niet wanneer je het profiel herlaadt.

Op Windows heeft dezelfde vraag een ander commando. Find-NetRoute -RemoteIPAddress 192.168.50.10 drukt de interface en de volgende hop af die de stack zou kiezen, en route print -4 laat zien of het gepushte prefix eigenlijk wel bestaat.

Stap twee: bevestig dat de server het pakket doorstuurt

Als de clientroute klopt, bereikt het pakket de server en de server moet instemmen met doorsturen. De kernelschakelaar is de eerste poort, en sysctl net.ipv4.ip_forward moet 1 teruggeven. Instellen met echo 1 > /proc/sys/net/ipv4/ip_forward werkt tot de volgende herstart, en precies daarom komt dezelfde klacht weken later terug.

Schrijf het op een plek die een herstart overleeft:

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

De tweede poort is de filtertabel. Een host met Docker geïnstalleerd heeft vaak een FORWARD-beleid van DROP, en de tunnel erft die beslissing. iptables -L FORWARD -v -n toont zowel het beleid als de pakkettellers; is het beleid DROP, dan heeft doorsturen een expliciete toestemming nodig voor de richting tunnel naar LAN en een voor het antwoord.

Stap drie: volg het pakket naar de LAN en zoek het antwoord

Houd beide kanten van de server tegelijk in de gaten. Leg vast op de tunnel en op de LAN-interface, gefilterd op één client en één host zodat de uitvoer leesbaar blijft:

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

Verzoeken die op tun0 en opnieuw op eth0 verschijnen met een bron van 10.8.0.x, gevolgd door stilte, betekenen dat het pakket aankwam en het antwoord ergens anders heen ging. De LAN-host antwoordt zijn standaardgateway, die gateway heeft geen route voor de VPN-pool, en het antwoord sterft op de LAN-router. De LAN-host vanaf de server pingen bewijst niets over deze weg, omdat dat verkeer de tunnel nooit oversteekt.

Stap vier: kies tussen vertaling en een retourroute

Twee reparaties dichten het gat, en de keuze heeft gevolgen die verder gaan dan of ping werkt. Brontranslatie maakt de server de schijnbare afzender:

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

Beperk de regel tot de pool en de LAN-interface, maak hem dan permanent, anders verwijdert de volgende firewall-herlaadbeurt je fix stilzwijgend. De prijs is identiteit: elke client ziet er in LAN-logs en toegangsregels uit als de VPN-server, en per-client policy becomes guesswork.

Een statische route voor 10.8.0.0/24 op de LAN-router, die naar de VPN-server wijst, houdt clientadressen zichtbaar en is het betere antwoord op lange termijn wanneer die router van jou is. Veel locaties draaien een tijdje beide, NAT voor de onmiddellijke reparatie en de route zodra het firewallbeleid is geschreven. Is de server een site-to-site-peer in plaats van een pool, dan heeft de serverkant ook een iroute nodig voor het externe subnet, anders bestaat de peer-route wel maar wordt clientverkeer er nooit aan gekoppeld.

Stap vijf: verifieer vanaf de client en noteer wat er is veranderd

Sluit de lus vanaf de client, niet vanaf de server. Verbind met een echte dienst op de LAN-host en bevestig dan dat de vertaaltellers zijn opgeschoven met iptables -t nat -L POSTROUTING -v -n, want een regel met nul pakketten is een regel die nooit heeft gematcht. conntrack -L -s 10.8.0.5 toont de stroom en zijn toestand wanneer je bewijs nodig hebt dat de retourrichting wordt gevolgd.

Laat een notitie achter in de serverconfiguratie: welk subnet, welke interface, welke regel, en of de LAN-router een route terug heeft. De volgende keer dat een client-upgrade een gepushte route wist, verandert die notitie een brandbestrijdingssessie in een fix van één regel.