Waarom een full-tunnel-VPN je gerouteerde lokale VLAN's verbergt

De schakelaar “lokaal netwerk toestaan” in een VPN-client klinkt alsof hij alles in het gebouw dekt. In de praktijk voegt hij meestal een paar uitzonderingen voor privéadressen toe aan de standaardroute van de tunnel en stopt daar. Je opslag-VLAN blijft alleen bereikbaar als een route voor dat specifieke prefix de komst van de tunnel overleeft, en bij veel clients gebeurt dat niet.

Dat is een routeringsvraagstuk en geen VPN-instelling, wat goed nieuws is: er is een concreet antwoord.

Wat lokaal netwerk toestaan echt dekt

Clients implementeren die optie verschillend. Sommige voegen routes toe voor het subnet waaraan de machine hangt, sommige voegen de RFC 1918-reeksen toe, en enkele sluiten alleen de standaardgateway uit. Geen van hen weet dat je kantoorrouter ook een opslag-VLAN, een labsegment of een printersubnet bedient, want die prefixes staan niet op het net dat de client kan zien. Lees de eigen documentatie van de client voor het exacte gedrag in plaats van aan te nemen dat het label je topologie beschrijft.

Het verschil is het belangrijkst in een full-tunnelontwerp, waarbij de client opzettelijk de standaardroute vervangt zodat al het verkeer door de VPN gaat. Dat is het hele doel van het ontwerp, en dat is ook wat de lokaal gerouteerde netwerken laat verdwijnen. Ze werden nooit door een eigen route gedekt; ze liftten mee op de standaardroute die zojuist is vervangen. Een client kan niet routeren wat hij niet weet dat bestaat, en hij leert alleen prefixes kennen die aan zijn eigen interface hangen. Al het andere moet worden beschreven door iemand die de topologie kent.

Verbonden routes stoppen bij de eerste router

Een werkstation op 192.168.10.20/24 met gateway 192.168.10.1 krijgt automatisch een verbonden route voor 192.168.10.0/24. Het opslag-VLAN op 192.168.20.0/24 is een ander prefix, alleen bereikbaar via die gateway, en het werkstation heeft daarvoor geen route buiten de standaardroute. Voordat de tunnel opkomt, stuurt de gewone standaardroute opslagverkeer naar 192.168.10.1 en werkt alles.

Wanneer de VPN een full-tunnelstandaard installeert, volgen pakketten voor 192.168.20.1 de nieuwe standaardroute de tunnel in. De externe gateway weet niet waar dat prefix ligt, dus laat hij ze vallen of stuurt hij ze naar een nutteloze plek. Er was niets verkeerd geconfigureerd op het opslag-VLAN; het pad was geleend, en de lening werd opgeëist.

De verleiding is om naar een brede uitzondering te grijpen, zoals een /1-rutepaar of een tweede standaardroute. Weersta die. Hoe smaller de uitzondering, hoe gemakkelijker hij is uit te leggen, te controleren en te verwijderen wanneer het netwerk verandert.

Zet de uitzondering in de tabel die wint

Binnen één routingtabel wint een /24 van een /0 of /1 door de langste-prefixmatch, dus een specifieke route naar het opslag-VLAN via de lokale gateway is genoeg, mits de tabel überhaupt wordt geraadpleegd. Op Linux is de gewone vorm kort:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Policy-routing maakt die garantie ingewikkelder. Een eerdere regel kan verkeer naar een tabel sturen waarvan de eigen standaardroute de tunnel in wijst, en de hoofdtabel met jouw /24 wordt dan nooit bereikt. Controleer de regels voordat je aanneemt dat de route gezaghebbend is, want een correct uitziende vermelding in de verkeerde tabel verklaart een storing die op een kapotte route lijkt.

Maak de vermelding daarna permanent via het door de client ondersteunde mechanisme of de netwerkbeheerder die de interface bezit. Een route die je bij de prompt typt, verdwijnt bij de volgende herverbinding, en een route die aan één Wi-Fi-gateway hangt, is niet overdraagbaar naar het volgende netwerk dat de laptop bezoekt.

Namen en beleid volgen geen routes

Het repareren van de route herstelt pakketten, niet namen. Als lokale apparaten worden opgelost via een gepushte resolver die niets van hen weet, mislukt de mount nog steeds terwijl het adres bereikbaar is. Lokale namen vereisen een lokale of gesplitste DNS-regeling, en dat is een aparte beslissing naast de route-uitzondering.

Beleid staat weer apart. Het lokale-toegangsfilter van een VPN-client kan verkeer naar privéreeksen opzettelijk verbieden, en een route gaat niet boven die regel. Op een onvertrouwd netwerk is een privéadres ook geen bewijs dat de bestemming je opslagserver is, dus de uitzondering moet net zo specifiek zijn als de route zelf.

Een contract dat je kunt overdragen

Het voltooide ontwerp moet als een korte lijst te lezen zijn: algemeen internetverkeer volgt de tunnel, en deze genoemde lokale prefixes houden hun pad via de lokale router. Schrijf de prefixes, de next hop en het bijbehorende DNS-suffix op, en houd de lijst kort genoeg zodat iemand hem kan verifiëren zonder een routingtabel te lezen.

Let op overlap tussen lokale en externe reeksen. Een opslag-VLAN dat een prefix deelt met iets achter de VPN, wordt opgelost naar de route die specifieker is, en het resulterende gedrag is verwarrend op een manier die intermitterend lijkt. Eén kant hernummeren is meestal goedkoper dan die dubbelzinnigheid voor altijd te debuggen.

Test het contract twee keer: één keer met de tunnel op en één keer met de tunnel neer. Als het lokale pad maar in één van die toestanden werkt, is de uitzondering nog geen contract.