LAN-router plus VPN-client: twee apparaten, twee routetabellen

Twee apparaten sturen het pakket door en elk houdt zijn eigen tabel bij. De LAN-router weet dat het externe prefix bij de VPN-client hoort, en de VPN-client weet hoe hij dat prefix via zijn tunnel bereikt. Configureer alleen de eerste tabel en het pakket komt aan bij een machine zonder passende route, dus het verlaat die weer via de standaardroute. Dat is de hele fout, en vanaf de LAN-kant lijkt het op een routeringslus, omdat het er bijna een is.

Teken de twee hops voordat je een route aanraakt

Neem een illustratieve opzet: LAN-hosts op 192.168.50.0/24, de gewone router op 192.168.50.1, een aparte client op 192.168.50.15 en een extern LAN op 10.60.0.0/24 dat alleen bereikbaar is via de tunnel die die client heeft. Geen van de twee privébereiken overlapt het andere, en de tunnel heeft zijn eigen adresplan.

Beide privébereiken doen ertoe, omdat ze bepalen welk apparaat kan antwoorden. De externe kant ziet het pakket aankomen vanaf het tunneladres van de client, en het antwoord moet een weg terug vinden naar 192.168.50.0/24. Als alleen de uitgaande richting is geconfigureerd, kan het verzoek werken terwijl het antwoord verdwijnt.

Stap 1: richt de router op de client, niet op de tunnel

Voeg op de LAN-router een bestemmingsroute toe waarvan de volgende hop het LAN-adres van de client is:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Die regel zegt „lever het af bij de machine die kan tunnelen”. Hij zegt niets over hoe de tunnel wordt gebouwd, en hij vervangt niet de eigen route van de client. Op een beheerde router staat het equivalent op de pagina voor statische routes van het apparaat; op een Linux-router hoort het bij de interfaceconfiguratie die de LAN bezit, niet in een shell die je sluit.

Controleer het antwoord van de tweede opdracht. Als die de client als gateway en de LAN-interface als device meldt, is de eerste hop juist en ligt het resterende werk op de andere machine.

Stap 2: geef de client een eigen route aan de tunnelkant

De client ontvangt nu een pakket voor 10.60.0.0/24 en kijkt in zijn eigen tabel. Als zijn tunnelconfiguratie een route voor dat prefix heeft geïnstalleerd, gaat het pakket versleuteld verder. Zo niet, dan past het pakket op de gewone standaardroute en gaat het terug naar 192.168.50.1, dat het opnieuw naar de client stuurt.

Kijk voordat je iets toevoegt:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Een ontbrekende prefixroute in alle tabellen is de bevinding die je zoekt. Voeg hem toe via de eigen configuratie van de tunnel, zodat de volgende herverbinding hem opnieuw installeert; een handmatige ip route add verdwijnt met de sessie en laat de fout op het minst gelegen moment terugkomen. De volgende hop is de tunnelinterface of het adres dat de VPN als zijn peer toewijst, afhankelijk van de client, en het peeradres hoort uit het huidige profiel te komen en niet uit een oude notitie.

De lus is, wanneer die optreedt, in de praktijk niet oneindig: de TTL daalt bij elke doorgang en het pakket sterft met een time-exceeded-bericht. Daarom kan een herhaalde traceroute een cyclus suggereren, terwijl een client die simpelweg niet doorstuurt hetzelfde pakket stil laat vallen.

Stap 3: sta doorsturen toe en kies de terugweg

Ontvangen en doorsturen zijn verschillende rechten. net.ipv4.ip_forward=1 op de client staat transit op kernelniveau toe, en een firewallregel moet dat nog steeds toestaan tussen de LAN-interface en de tunnel. Een regel die toegang tot de eigen beheerpagina van de client toestaat, staat geen transit naar het externe LAN toe, en het onderscheid is makkelijk te missen wanneer dezelfde host lokaal op pings antwoordt.

De externe kant heeft het spiegelprobleem. Die moet weten dat 192.168.50.0/24 bereikbaar is via deze geauthenticeerde client. Met OpenVPN betekent dat meestal een route per client die de serverconfiguratie erin duwt, of een clientspecifiek bestand op de server dat het LAN achter de client verklaart. Zonder dat laat het externe LAN het antwoord vallen of stuurt het naar zijn eigen standaardgateway, namelijk het internet.

Bronvertaling is het alternatief wanneer het LAN-prefix niet kan worden aangekondigd. Een beperkte masquerade-regel op de client herschrijft de bron naar het tunneladres, en antwoorden komen dan vanzelf terug. Het verbergt ook welke LAN-host het verzoek deed, en het staat de externe kant niet op zichzelf toe verbindingen naar binnen te starten. Kies die afweging bewust in plaats van een algemene masquerade toe te voegen en het neveneffect later te ontdekken.

Stap 4: maak beide beslissingen blijvend en test dan het echte pad

Elke route heeft een eigenaar, en de eigenaar is de configuratie die bij het opstarten of bij herverbinding opnieuw wordt gemaakt. Op de router kan dat een statische route zijn; op de client kan dat het VPN-profiel, NetworkManager of systemd-networkd zijn. Verifieer door de tunnel opnieuw te verbinden en de client te herstarten, en lees daarna de tabel opnieuw in plaats van de wijziging te vertrouwen.

Houd de standaardroute die de buitenste verbinding van de tunnel draagt intact. Die vervangen om de opzet te „vereenvoudigen” breekt het versleutelde pad voordat enig binnenverkeer het kan gebruiken, en het symptoom is een tunnel die na de wijziging nooit meer tot stand komt.

Test vanaf een gewone LAN-host, niet vanaf de client, omdat een verzoek dat op de client ontstaat nooit de eerste hop van de router oefent. Haal een dienst op die alleen op het externe LAN bestaat en bevestig de antwoordtekst, en kijk dan naar de tellers of logs van de client om de transit te zien gebeuren. Een interne traceroute met privé-hops bewijst doorsturen, niet versleuteling: het buitenste pad is een aparte observatie, en alleen de interfacetellers van de tunnel zelf laten zien wat erdoor naar buiten ging.