VPN-Adresse gegen LAN-DHCP-Zuweisung: Wer hat die Tunnel-IP vergeben?

Verbinden Sie den Client und sehen Sie sich den Adapter an statt das Wi-Fi-Symbol. Eine Adresse wie 10.80.0.14 kann auf einem Tunnel liegen, obwohl kein DHCP-Server im Büro-LAN diese Zuweisung je vermerkt hat. Welcher Prozess die Nummer gewählt hat, entscheidet, wo die Fehlersuche beginnt.

Auf dem Client sieht alles gleich aus: eine IPv4-Adresse, eine Maske, manchmal ein Standardgateway. Der Unterschied zeigt sich erst, wenn Sie fragen, wer für diese Adresse antwortet und wer darüber Buch führt.

Die Tunneladresse aus Sicht des Clients lesen

Windows zeigt den Unterschied, wenn Sie den ganzen Block lesen statt der ersten Zeile. ipconfig /all gibt Adapterbeschreibung, physische Adresse und eine DHCP-Zeile aus. Ein PPP- oder IKEv2-Wähladapter meldet DHCP normalerweise als deaktiviert, weil die Verbindung ihre Adresse während des Wählens ausgehandelt hat, statt sie von einem LAN-Server zu mieten. Ein Tunneladapter mit aktiviertem DHCP ist ungewöhnlich und für sich untersuchenswert.

Linux verteilt dieselbe Information auf zwei Werkzeuge. ip -4 addr show dev tun0 liefert Adresse und Präfixlänge. nmcli -f IP4 connection show work zeigt, ob der Wert aus dem Verbindungsprofil, einem DHCP-Austausch auf der Strecke oder einer geschobenen Konfiguration stammt. WireGuard ist der klarste Fall: wg-quick wendet beim Erscheinen der Schnittstelle die Zeile Address aus der Konfigurationsdatei an, und kein Peer teilt beim Verbinden etwas zu.

Auch das Präfix sagt etwas. Ein /32 oder eine Maske von 255.255.255.255 bedeutet, dass das Gateway auf eine einzelne Hostadresse routen will, während eine breitere Maske auf ein On-Link-Subnetz irgendwo hinter dem Tunnel hindeutet.

Was die IKEv2-Konfigurationsnutzlast trägt

IKEv2 hat dafür einen eigenen Mechanismus. Die in RFC 7296, Abschnitt 3.15.1 beschriebene Konfigurationsnutzlast trägt Attribute wie INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS und ihre IPv6-Gegenstücke. Der Client sendet ein Attribut mit Länge null, wenn er keine Präferenz hat, und der Responder gibt den Wert zurück, der verwendet werden soll. Dieser Austausch läuft innerhalb von IKE_AUTH, bereits verschlüsselt, sodass kein DHCP-Broadcast je den Tunnel überquert.

Daraus folgen zwei Dinge. Erstens wählt der Responder die Adresse oder das Autorisierungs-Backend, das er befragt; deshalb kann ein Pool am Gateway, in einer RADIUS-Antwort oder in einer Zuordnung des Identitätsanbieters liegen. Zweitens ist das DNS-Attribut vom Adressattribut getrennt. Der Empfang von 10.80.0.14 sagt nichts darüber, welcher Resolver zurückkam oder ob überhaupt einer kam.

Das Netzmasken-Attribut ist in der Praxis optional. Viele Installationen geben nur eine Adresse zurück und lassen den Client eine Hostroute setzen, weshalb derselbe Pool auf einem Client wie ein /32 und auf einem anderen wie ein /24 aussehen kann.

Wo LAN-DHCP-Bereich und VPN-Pool kollidieren

Ärger beginnt, wenn beide Zuteiler auf denselben Bereich zeigen. Ein DHCP-Server für 10.20.30.0/24 weiß nichts von einem VPN-Pool für 10.20.30.128/25, also hindert ihn nichts daran, 10.20.30.140 an einen Drucker zu vergeben, während das Gateway dieselbe Adresse an einen entfernten Client ausgibt. Die Kollision bleibt tagelang still und zeigt sich dann als sporadisches Duplikat.

Ein geroutetes Site-to-Site-Design vermeidet die Kollision konstruktiv. Ein Host in der Filiale behält die Adresse, die ihm der lokale DHCP-Server gegeben hat. Die Tunnel-Schnittstellen auf beiden Gateways tragen ihre eigenen Linkadressen, und die Routing-Tabelle entscheidet, wie Pakete reisen. Adressen von Fernzugriffsclients sind eine dritte Kategorie und sollten nicht mit Linkadressen des Gateways vermischt werden.

Den Tunnel ins LAN zu brücken hebt diese Trennung auf. Braucht das Design wirklich eine Broadcast-Domäne, muss der VPN-Endpunkt an denselben Zuteilungsentscheidungen teilnehmen wie der DHCP-Server, über einen Relay oder eine gemeinsame autoritative Quelle, statt Adressen selbst auszugeben.

Prüfen, welcher Prozess die Adresse besitzt

Belegen Sie den Besitz, bevor Sie einen Bereich ändern. Notieren Sie am Client Adresse und Präfix. Suchen Sie im LAN die Zuweisungsdatenbank. Listen Sie am Gateway die Pools auf, die es ausgeben soll. Eine Adresse aus der Zuweisungsdatei gehört einem DHCP-Server, der Tunnel ist also gebrückt oder weitergeleitet; eine Adresse nur aus dem Gateway-Pool gehört dem Tunnel-Endpunkt.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Halten Sie vier Dinge fest, sobald die Antwort klar ist: welche Komponente die Clientadresse zuteilt, welcher Bereich dafür reserviert ist, wie Rückverkehr diesen Bereich erreicht und welche Ressourcen sie akzeptieren. Diese vier Einträge machen aus einer virtuellen Adapterzeile einen Betriebsfakt.

Wiederholen Sie die Prüfung für das DNS-Attribut, solange Sie dort sind. Ein Pool, der Adressen ohne Resolver ausgibt, lässt den Client auf seinem lokalen DNS, was ein anderer Fehler ist als ein Pool, der eine Adresse ausgibt, die das LAN bereits nutzt.