Ihr VPN-Pool ist nicht der DHCP-Bereich des LAN: warum das bricht

Die verlockende Abkürzung ist, VPN-Clients Adressen aus demselben Bereich zu geben, den der DHCP-Server im Büro verwendet, in der Annahme, ohnehin sei alles ein Netz. Ist es nicht. Ein gerouteter Tunnel überträgt Unicast-Pakete zwischen zwei Endpunkten, während der LAN-Pool dazu dient, Broadcast-Anfragen auf einem physischen Segment zu beantworten. Dieselben Nummern erneut zu verwenden, setzt zwei Zuteiler für einen Adressraum ein und lässt den Rückweg undefiniert.

Zwei Zuteiler, ein Adressraum

Der DHCP-Server im LAN weiß, welche Adressen er an welche MAC-Adresse vergeben hat, und verteidigt sie per ARP. Der VPN-Server hat seinen eigenen Pool und weiß nichts von diesen Leases. Keiner von beiden irrt sich; man hat sie nie einander vorgestellt.

Eine Adresse aus dem LAN-Pool, die der VPN-Server vergibt, kann bereits einem Drucker gehören. Nun beanspruchen zwei Geräte eine Adresse im selben Präfix, und die Forwarding-Tabelle des Switches entscheidet, welches antwortet.

Das ist der Fehler, auf den Menschen zuerst stoßen: ein Client, der sich erfolgreich verbindet und dann die falsche Maschine erreicht, oder die richtige nur zeitweise erreicht.

Warum der Router keine VPN-Adressen verteilt

DHCP-Erkennung ist ein Broadcast, und Broadcasts enden an einer gerouteten Grenze. Wenn das Design den Tunnel nicht bridgt oder einen DHCP-Relay mit passender Berechtigung betreibt, erreicht die Anfrage des Clients den LAN-Server nie.

Deshalb vergibt der VPN-Server die Adresse selbst: einen Pool in der Serverkonfiguration, eine Adresse pro Peer in einer WireGuard-Einrichtung, oder eine Adresse, die die Authentifizierungsschicht in einem IKEv2-Deployment durchreicht. Diese Mechanismen sind unabhängig von der Lease-Datenbank des LAN, und genau deshalb brauchen sie einen eigenen Bereich.

Dieselbe Logik erklärt, warum das Ändern des DHCP-Bereichs einen VPN-Client nicht repariert, der nie eine Adresse bekommt. Der Client fragt den LAN-Server nicht, und keine Bearbeitung des Bereichs bringt ihn dazu.

Die Überschneidung zeigt sich als Konflikt, nicht als langsames Netz

Zwei Netze, die ein Präfix ohne tragfähiges Design teilen, sind ein anderes Problem als doppelte Zuständigkeit, und sie werden oft verwechselt. Ist der VPN-Pool ein eigenes Präfix, zählt die Überschneidung nur, wenn eine Route Verkehr auf die falsche Seite schickt. Liegt der Pool innerhalb des LAN-Präfixes, ist der Konflikt sofort und lokal.

In der Praxis sieht man ARP-Antworten vom falschen Gerät, Verbindungen, die mittendrin zurücksetzen, und einen Client, dessen eigene Adresse jemand anders beansprucht. Nichts davon sieht nach einem Routingproblem aus, deshalb wird die Korrektur auf der falschen Schicht angesetzt. Eine doppelte Lease ist leicht zu bestätigen und lästig im Alltag. Sie übersteht auch Neustarts, weil beide Zuteiler weiter auf derselben Adresse bestehen.

Der Rückweg ist ein eigenes Problem

Selbst mit einem sauberen, getrennten Pool müssen LAN-Hosts wissen, wie sie einem Client antworten. Ihr Standardgateway ist der Router, und der Router braucht eine Route für den Pool zum VPN-Server, es sei denn, das Design übersetzt stattdessen den Client-Verkehr.

Lesen Sie den Pfad in beide Richtungen, bevor Sie etwas ändern. Fragen Sie am Gateway, welche Schnittstelle der Kernel für eine Client-Adresse verwenden würde; fragen Sie am Client, welche Route er für eine LAN-Adresse nutzt.

Diese Befehle zeigen die Weiterleitungsentscheidung am Gateway und die Nachbareinträge, die ein Duplikat verraten:

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

Antwortet der erste Befehl mit der Tunnel-Schnittstelle, existiert die Rückroute. Antwortet er mit der LAN-Schnittstelle, glaubt der Router, der Client sei am Draht, und wird ARP für ihn versuchen.

Gebridgte Designs gibt es, aber sie müssen gewählt werden

Einen Tunnel ins LAN zu bridgen ist ein echtes Design, das genutzt wird, wenn Clients Broadcasts empfangen müssen oder von Protokollen entdeckt werden sollen, die ein Segment annehmen. Es verlangt, dass der Server dieses Bridge-Verhalten besitzt und die Adressbehandlung, die dazugehört.

Was nicht funktioniert, ist, das Ergebnis durch Kopieren von Nummern nachzuahmen. Ein geteilter Pool ohne Bridge liefert den Konflikt ohne die Entdeckung, was das Schlechteste beider Anordnungen ist.

Wählen Sie Schicht drei mit einem getrennten Pool, es sei denn, die Anwendung braucht das Segment wirklich, und dokumentieren Sie den Pool, damit der nächste Administrator den DHCP-Bereich nicht aus Ordnungsliebe wiederverwendet.