DHCP über ein VPN: Broadcast brücken oder weiterleiten?
Clients auf der anderen Seite eines Tunnels bekommen keine Adresse. Entscheiden Sie, ob der Broadcast getragen oder weitergeleitet wird, und halten Sie DHCP von ARP getrennt.
Ein neuer Laptop auf der anderen Seite des Tunnels bekommt keine Adresse, während derselbe Laptop in der Zentrale funktioniert. Die übliche erste Vermutung ist, dass der Tunnel DHCP blockiert. Häufiger hatte der Broadcast nie einen Weg: Ein nicht konfigurierter Client sendet an 255.255.255.255, und ein gewöhnlicher IP-Router leitet dieses Paket nicht weiter. Der Tunnel tut genau das, was ein gerouteter Tunnel tut.
Zwei Entwürfe können das ändern, und sie sind nicht gleichwertig. Der eine trägt den Broadcast; der andere leitet die Anfrage weiter.
Der Broadcast überquert den Router nie
Ein DHCPv4-Client ohne Adresse sendet von 0.0.0.0 an die begrenzte Broadcast-Adresse auf den UDP-Ports 67 und 68. Dieses Paket bleibt konstruktionsbedingt auf seinem Link. Ein Router, der es weiterleitete, würde jedes von ihm bediente Segment fluten.
Ein gerouteter Standort-zu-Standort-Tunnel verbindet also den Relay mit einem Server. Er erweitert die Broadcast-Domäne des Clients nicht, und keine Firewall-Regel wird das bewirken.
Was ein gebrückter Tunnel tatsächlich erweitert
Ein bewusst gebrücktes VPN kann Ethernet-Broadcast innerhalb seiner unterstützten Topologie tragen, und dann kann DHCP als lokaler Verkehr passieren. Das ist eine echte Option, aber eine Designentscheidung auf Schicht 2. Sie erweitern die Fehlerdomäne und die Zugriffsgrenze zusammen mit dem Broadcast.
Brücken ändert auch, was ein Broadcast-Sturm, ein ARP-Scan oder ein bösartiger DHCP-Server erreichen kann. Wenn Sie die Außenstelle nicht an denselben Switch stecken würden, brücken Sie den Tunnel nicht nur, um Adressen zu verteilen. Testen Sie diesen Wirkungsradius, bevor Sie ihn aktivieren.
Es ist eine größere Entscheidung als die Vergabe einer Adresse, und sie sollte bewusst getroffen werden.
Leiten Sie stattdessen die Anfrage weiter
Die übliche Antwort ist ein Relay im lokalen Netz des Clients. Es empfängt den Broadcast, wandelt ihn in eine Unicast-Anfrage um und trägt seine eigene Adresse in das Gateway-Adressfeld ein. Der Server antwortet an diese Relay-Adresse.
Bei einer beispielhaften Außenstelle sitzt das Relay im LAN der Außenstelle, und der Server wird über das Standort-VPN erreicht. Konfigurieren Sie den Bereich für diese Außenstelle, die Identitäten von Relay und Server sowie den vollständigen Rückweg. UDP 67 durch den Tunnel zuzulassen sagt dem Server nicht, welcher Pool zu verwenden ist.
Ein Relay, das weiterleitet, aber nie eine Antwort erhält, ist meist ein Rückwegproblem. Prüfen Sie die Route zurück zur Relay-Adresse, bevor Sie den Bereich ändern.
Trennen Sie DHCP von ARP und von der Tunneladressierung
DHCP läuft über UDP/IP. Auf Ethernet kann ein Host auch ARP verwenden, um zu prüfen, ob eine Kandidatenadresse bereits belegt ist. Diese Konfliktprüfung ist ein eigener linklokaler Vorgang, nicht der Transport für DHCP-Nachrichten. Zu sagen, DHCP sei im Wesentlichen ARP, ist falsch; zu sagen, die beiden hätten nie miteinander zu tun, ist zu weit gefasst.
Ein VPN-Client kann seine Tunneladresse auch vom VPN-Protokoll oder aus dem eigenen Pool des Servers beziehen statt aus einem DHCP-Broadcast. Eine Option, deren Name DHCP enthält, kann gepushte Client-Einstellungen beschreiben, nicht ein weitergeleitetes DHCP-Paket. Prüfen Sie den Pool des Servers, bevor Sie annehmen, dass DHCP überhaupt beteiligt ist.
Halten Sie das Empfängernetz, den Eigentümer der Zuweisung, den Bereich, ob ein Relay existiert und das erwartete Verhalten bei einem Ausfall fest. Testen Sie dann eine neue Lease und eine Erneuerung über dieses Modell. Wenn zwei Standorte denselben unverwalteten Pool bedienen können, haben Sie einen Konflikt, der auf den ersten wandernden Laptop wartet.