Je VPN-pool is niet het DHCP-bereik van de LAN: waarom het breekt

De verleidelijke kortere weg is om VPN-clients adressen te geven uit hetzelfde bereik dat de DHCP-server van kantoor gebruikt, in de veronderstelling dat alles toch één netwerk is. Dat is het niet. Een gerouteerde tunnel vervoert unicast-pakketten tussen twee eindpunten, terwijl de LAN-pool bestaat om broadcast-verzoeken op een fysiek segment te beantwoorden. Dezelfde nummers hergebruiken zet twee toewijzers verantwoordelijk voor één adresruimte en laat het retourpad ongedefinieerd.

Twee toewijzers, één adresruimte

De DHCP-server van de LAN weet welke adressen hij heeft verhuurd en aan welk MAC-adres, en verdedigt ze met ARP. De VPN-server heeft zijn eigen pool en weet niets van die leases. Geen van beide zit fout; ze zijn alleen nooit aan elkaar voorgesteld.

Een adres uit de LAN-pool dat de VPN-server uitgeeft, kan al van een printer zijn. Nu claimen twee apparaten één adres op dezelfde prefix, en de forwardingtabel van de switch beslist welke antwoordt.

Dat is de storing die mensen het eerst tegenkomen: een client die met succes verbindt en dan bij de verkeerde machine uitkomt, of de juiste met tussenpozen bereikt.

Waarom de router geen VPN-adressen uitgeeft

DHCP-ontdekking is een broadcast, en broadcasts stoppen bij een gerouteerde grens. Tenzij het ontwerp de tunnel overbrugt of een DHCP-relay met passende bevoegdheid draait, bereikt het verzoek van de client de LAN-server nooit.

Daarom wijst de VPN-server het adres zelf toe: een pool in de serverconfiguratie, een adres per peer in een WireGuard-opstelling, of een adres dat de authenticatielaag doorduwt in een IKEv2-implementatie. Die mechanismen zijn onafhankelijk van de leasedatabase van de LAN, en precies daarom hebben ze een eigen bereik nodig.

Dezelfde redenering verklaart waarom het wijzigen van de DHCP-scope een VPN-client die nooit een adres krijgt niet repareert. De client vraagt de LAN-server niet, en geen enkele bewerking van de scope krijgt hem zover.

De overlap verschijnt als conflict, niet als een traag netwerk

Twee netwerken die een prefix delen zonder ondersteund ontwerp zijn een ander probleem dan dubbel eigendom, en ze worden vaak verward. Als de VPN-pool een aparte prefix is, doet overlap er alleen toe wanneer een route verkeer naar de verkeerde kant stuurt. Als de pool binnen de LAN-prefix ligt, is het conflict onmiddellijk en lokaal.

In de praktijk zie je ARP-antwoorden van het verkeerde apparaat, verbindingen die halverwege resetten, en een client wiens eigen adres door iemand anders wordt geclaimd. Niets daarvan lijkt op een routeringsprobleem, daarom wordt de oplossing op de verkeerde laag toegepast. Een dubbele lease is makkelijk te bevestigen en vervelend om mee te leven. Hij overleeft ook herstarts, omdat beide toewijzers op hetzelfde adres blijven aandringen.

Het retourpad is een apart probleem

Zelfs met een schone, aparte pool moeten LAN-hosts weten hoe ze een client antwoorden. Hun standaardgateway is de router, en de router heeft een route voor de pool nodig die naar de VPN-server wijst, tenzij het ontwerp in plaats daarvan clientverkeer vertaalt.

Lees het pad in beide richtingen voordat je iets wijzigt. Vraag op de gateway welke interface de kernel voor een clientadres zou gebruiken; vraag op de client welke route hij voor een LAN-adres gebruikt.

Deze opdrachten tonen de doorstuur-beslissing op de gateway en de buurvermeldingen die een duplicaat verraden:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Als de eerste opdracht met de tunnelinterface antwoordt, bestaat de retourroute. Als hij met de LAN-interface antwoordt, denkt de router dat de client aan de kabel zit en zal hij ARP voor hem proberen.

Overbrugde ontwerpen bestaan, maar ze moeten worden gekozen

Een tunnel naar de LAN overbruggen is een echt ontwerp, gebruikt wanneer clients broadcasts moeten ontvangen of ontdekt moeten worden door protocollen die één segment veronderstellen. Het vereist dat de server dat brug-gedrag en de adresafhandeling die erbij hoort bezit.

Wat niet werkt, is het resultaat nabootsen door nummers te kopiëren. Een gedeelde pool zonder brug geeft je het conflict zonder de ontdekking, wat het slechtste van beide regelingen is.

Kies laag drie met een aparte pool, tenzij de toepassing het segment echt nodig heeft, en documenteer de pool zodat de volgende beheerder het DHCP-bereik niet uit netheid hergebruikt.