Geef LAN-hosts een VPN-terugroute met DHCP-optie 121

Externe VPN-clients verbinden, de LAN-server antwoordt, en het antwoord verlaat het netwerk via de gewone internetrouter en sterft daar. Eén server is te repareren met een statische route, maar een heel subnet ervan kun je beter behandelen waar ze hun netwerkconfiguratie al krijgen. DHCPv4-optie 121 distribueert precies dat soort bestemmingsroute, en dat is het deel dat mensen meestal verkeerd doen zodra ze de standaard vergeten. Het symptoom is eenrichtingsverkeer: verzoeken komen aan en antwoorden verdwijnen.

Benoem eerst de drie adressen

Neem een concreet LAN: 192.168.50.0/24 met de gewone standaardrouter op 192.168.50.1 en een aparte VPN-gateway op 192.168.50.2. Geauthenticeerde externe clients bezetten 10.90.0.0/24.

De route die elke deelnemende host nodig heeft, is 10.90.0.0/24 via 192.168.50.2. De bestemming is de clientpool, en de volgende hop is het LAN-adres van de gateway, niet het tunneladres.

Codeer hem als klasseloze statische route

Optie 121 draagt paren van prefix en volgende hop, en RFC 3442 definieert zowel de codering als het clientgedrag dat daaruit volgt. Voor een bestaande dnsmasq-instantie die alleen dit voorbeeld-LAN bedient, is de vorm van de configuratie:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

Dat is een fragment, geen nieuwe DHCP-dienst. Op een server die meerdere segmenten bedient, beperk je de optie met de tags of het netwerkbeleid die je al gebruikt. Houd de vorige configuratie bij de hand, want terugdraaien betekent nog een lease-verlenging, geen herstart.

Verlies de standaardroute niet

Dit is de valkuil. Een client die optie 121 ontvangt, moet de gewone Router-optie negeren, dus alleen de route van de VPN-pool aankondigen kan die host helemaal zonder standaardroute achterlaten. De machine ziet er nog steeds geconfigureerd uit en verliest stilletjes het internet. Gebruikers beschrijven dat als een netwerk dat plat ligt terwijl elke interface omhoog is.

Neem de bedoelde standaard op in dezelfde lijst, zoals het fragment hierboven doet. Houd ook de gewone Router-optie staan, voor clients die klasseloze routes niet implementeren; de eigen optieafhandeling van de server bepaalt wat naar wie gaat.

Controleer wat de client accepteert

Een host met een handmatig adres pikt dit nooit op, omdat hij geen lease aanvraagt. Clientondersteuning verschilt ook, dus test op het besturingssysteem dat je werkelijk draait in plaats van aan te nemen dat elk apparaat optie 121 respecteert. Bevestig met de eigenaren van die servers welke statisch geadresseerd zijn. Die hosts hebben hun eigen route-items nodig, anders doen ze gewoon niet mee.

Beheerde DHCP-diensten zijn een andere grens. Sommige cloudnetwerken laten beheerders geen willekeurige opties publiceren, en een concurrerende DHCP-server op hetzelfde segment is erger dan helemaal geen optie.

Controleer de lease, dan de lookup

Laat de DHCP-eigenaar de wijziging toepassen en vernieuw daarna de lease op een client. Bestaande leases houden de oude configuratie tot ze worden vernieuwd, dus directe resultaten zijn niet gegarandeerd.

Lees op een Linux-client de werkelijke routes en bevestig beide items:

ip -4 route
ip -4 route get 10.90.0.23

De contextuele lookup zou de poolroute via 192.168.50.2 en de standaard via 192.168.50.1 moeten tonen. Ontbreekt de standaard, dan heb je de valkuil hierboven gereproduceerd.

Test daarna de echte uitwisseling

Routedistributie is niet het hele pad. De aparte gateway heeft nog steeds doorsturen, eigendom van externe peers en een toegangsbeleid nodig dat de server toestaat, en DHCP authenticeert niemand.

Houd ten slotte een verwijderplan bij de hand. Een geleerde statische route trekt zich niet terug als de VPN uitvalt, dus een verouderde volgende hop kan dat prefix nog lang nadat de tunnel weg is in een zwart gat laten belanden.