VPN-clients bereiken de server wel, het LAN niet: welke oplossing?

De client pingt het tunneladres van de OpenVPN-server en krijgt antwoord, probeert dan een host op het LAN van de server en krijgt niets. Die splitsing vernauwt de fout flink: de tunnel staat, forwarding werkt waarschijnlijk, en het antwoord vertrekt via een deur die niet terugleidt. Er zijn drie oplossingen, en de juiste hangt af van wat u beheert en wat u wilt opgeven. Beantwoord de drie vragen hieronder in volgorde, dan is de keuze geen kwestie van smaak meer.

Eerst vaststellen welke richting stuk is

Het verzoek komt binnen op de tunnelinterface met een bronadres uit de VPN-pool. De server stuurt het door naar de LAN-host, en die host antwoordt aan de gateway die zijn eigen tabel noemt, meestal de LAN-router. Heeft de router geen route voor de pool, dan sterft het antwoord daar of dwaalt het richting internet.

Test beide machines voordat u een van beide aanpast. Vraag op de server aan de routingtabel hoe die een client zou bereiken; vraag op de LAN-host hoe die hetzelfde adres zou bereiken. De eerste lookup wijst meestal naar de tunnel en de tweede naar de LAN-router, en dat verschil is de fout in een regel. Twee lookups zijn goedkoper dan een firewallaudit en ze bepalen de richting van het probleem.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Wijst de LAN-host al naar de VPN-server, dan is uw probleem een firewallregel of een MTU-limiet en geen ontbrekende retourroute. Voeg geen route toe om een filter te repareren.

Vraag een: kunt u de router van het verre LAN aanpassen?

Is de LAN-router van u, dan is een statische route voor de VPN-pool met het LAN-adres van de VPN-server als next hop het nette antwoord. Die houdt de bronadressen van clients intact, wat telt wanneer LAN-hosts op adres loggen, filteren of snelheidslimieten opleggen. Ze vraagt ook geen vertaling op de server, zodat de tunnel een puur routeringspad blijft. De verplichting die ze schept is documentatie, want pool, route en serverconfiguratie moeten met elkaar kloppen.

Ze faalt stil op de dag dat iemand de pool wijzigt. Schrijf de waarde een keer op en behandel een wijziging op een van de drie plaatsen als een wijziging aan alle drie.

Een NAS of een Layer 3-switch die de dienst host, heeft dezelfde route nodig, tenzij hij alles via een router stuurt die er een heeft. Controleer het apparaat dat het subnet termineert, niet alleen het apparaat aan de internetkant. Kleine netwerken hebben vaak drie apparaten met een mening over routing.

Vraag twee: mag het LAN de clientadressen niet meer zien?

Hoort de router bij iemand anders, dan vraagt vertalen op de VPN-server geen medewerking. De LAN-host ziet het LAN-adres van de server, antwoordt daarop, en de server vertaalt terug. Daarom gedragen appliances en NAT-gebaseerde remote-access-rollen zich zo.

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

De prijs is toeschrijving: adressen per client verdwijnen uit de LAN-logs. Elke allowlist op de LAN-host moet dan de server noemen in plaats van de pool.

Kies vertaling wanneer medewerking niet beschikbaar is, niet wanneer ze alleen maar onhandig is. Ze verbergt de client voor elk toekomstig onderzoek, ook voor de gevallen waarin u moet weten welke laptop een verbinding opende. Ze kan ook protocollen breken die adressen in payloads opnemen, omdat de vertaling in de header zit. Geen van beide opties is geavanceerder; ze beantwoorden verschillende vragen over eigenaarschap.

Vraag drie: is de server zelf client van een andere tunnel?

Stel u de andere topologie voor: de VPN-server belt ook een commerciele provider in, dus heeft hij twee tunnels en twee sets adressen. Verkeer dat hij voor zijn eigen clients doorstuurt, verlaat het net via de provider, en die routeert antwoorden niet terug naar pooladressen. Daarom verdwijnen antwoorden terwijl beide tunnels gezond zijn.

De oplossing is ook de uitgaande tunnel te masqueraden, zodat de provider alleen het tunneladres van de server ziet. De omgekeerde richting heeft zijn eigen regel nodig, want de server die een verbinding opent naar een van zijn eigen clients is een andere flow. Zonder die regel antwoordt de client aan een adres dat hij niet kan routeren. Zet de smalle regel voor elke brede masquerade, zodat de specifieke vertaling wint.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Multihomed hosts voegen een verwante fout toe die er vanaf de client identiek uitziet. Het antwoord verlaat het systeem via de interface met de lagere metriek omdat het bronadres uit een andere tabel is gekozen. Controleer het retourpad met een lookup in plaats van aan te nemen dat het heenpad het impliceert.

Controleer daarna beide richtingen en beide groottes

Ping na de wijziging van de client naar een LAN-host en dan van de LAN-host naar de client. De tweede richting is degene die mensen overslaan, en zij is degene die een onvolledige vertaalregel blootlegt. Leg beide resultaten met tijdstempel vast, zodat een latere regressie vergelijkbaar is.

Verplaats dan echte data, want een kleine ping die slaagt terwijl een grote overdracht stokt is een MTU-symptoom. Die fout verschijnt meteen nadat u uzelf feliciteert met de gerepareerde route.

Test ten slotte opnieuw na een herstart. Runtime-opdrachten voor routes en firewall overleven die niet, en een oplossing die bij de volgende start verdwijnt, wordt opnieuw gediagnosticeerd door iemand met minder context. Maak de wijziging permanent zoals uw systeem dat al doet, en herstart dan een keer expres.