LAN-Hosts eine VPN-Rückroute per DHCP-Option 121 geben
Ein gemeinsames LAN kann die Route zu Ihrem VPN-Client-Pool per DHCP lernen. Kodieren Sie sie mit Option 121 und behalten Sie die Standardroute in derselben Liste.
Entfernte VPN-Clients verbinden sich, der LAN-Server antwortet, und die Antwort verlässt das Netz über den gewöhnlichen Internetrouter und stirbt dort. Ein Server lässt sich mit einer statischen Route reparieren, aber ein ganzes Subnetz davon behandelt man besser dort, wo sie ihre Netzwerkkonfiguration ohnehin beziehen. DHCPv4-Option 121 verteilt genau solche Zielrouten, und das ist der Teil, den Leute meist falsch machen, sobald sie den Standard vergessen. Das Symptom ist einseitiger Verkehr: Anfragen kommen an, Antworten verschwinden.
Benennen Sie zuerst die drei Adressen
Nehmen Sie ein konkretes LAN: 192.168.50.0/24 mit dem normalen Standardrouter auf 192.168.50.1 und einem separaten VPN-Gateway auf 192.168.50.2. Authentifizierte entfernte Clients belegen 10.90.0.0/24.
Die Route, die jeder teilnehmende Host braucht, ist 10.90.0.0/24 via 192.168.50.2. Das Ziel ist der Client-Pool, und der nächste Hop ist die LAN-Adresse des Gateways, nicht dessen Tunneladresse.
Kodieren Sie sie als klassenlose statische Route
Option 121 trägt Paare aus Präfix und nächstem Hop, und RFC 3442 definiert sowohl die Kodierung als auch das daraus folgende Clientverhalten. Für eine bestehende dnsmasq-Instanz, die nur dieses beispielhafte LAN bedient, sieht die Konfiguration so aus:
dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1
Das ist ein Fragment, kein neuer DHCP-Dienst. Auf einem Server, der mehrere Segmente bedient, grenzen Sie die Option mit den Tags oder der Netzwerkrichtlinie ein, die Sie bereits verwenden. Halten Sie die vorherige Konfiguration bereit, denn ein Rückbau bedeutet eine weitere Lease-Erneuerung, keinen Neustart.
Verlieren Sie die Standardroute nicht
Das ist die Falle. Ein Client, der Option 121 erhält, muss die gewöhnliche Router-Option ignorieren, also kann das Ankündigen nur der VPN-Pool-Route diesen Host ganz ohne Standardroute lassen. Die Maschine sieht weiterhin konfiguriert aus und verliert still das Internet. Nutzer beschreiben das als ausgefallenes Netz, während jede Schnittstelle oben ist.
Nehmen Sie den beabsichtigten Standard in dieselbe Liste auf, wie es das Fragment oben tut. Lassen Sie auch die gewöhnliche Router-Option stehen, für Clients, die klassenlose Routen nicht umsetzen; die eigene Optionsbehandlung des Servers entscheidet, was an wen geht.
Prüfen Sie, was der Client akzeptiert
Ein Host mit manueller Adresse übernimmt das nie, weil er keine Lease anfordert. Auch die Clientunterstützung ist unterschiedlich, testen Sie also auf dem Betriebssystem, das Sie tatsächlich einsetzen, statt anzunehmen, jedes Gerät befolge Option 121. Klären Sie mit den Eigentümern dieser Server, welche statisch adressiert sind. Diese Hosts brauchen eigene Routeneinträge, sonst nehmen sie schlicht nicht teil.
Verwaltete DHCP-Dienste sind eine weitere Grenze. Manche Cloud-Netze lassen Administratoren keine beliebigen Optionen veröffentlichen, und ein konkurrierender DHCP-Server im selben Segment ist schlimmer als gar keine Option.
Prüfen Sie die Lease, dann den Lookup
Lassen Sie den DHCP-Verantwortlichen die Änderung anwenden und erneuern Sie dann die Lease auf einem Client. Bestehende Leases behalten die alte Konfiguration, bis sie erneuert werden, sofortige Ergebnisse sind also nicht garantiert.
Lesen Sie auf einem Linux-Client die tatsächlichen Routen und bestätigen Sie beide Einträge:
ip -4 route
ip -4 route get 10.90.0.23
Der kontextbezogene Lookup sollte die Pool-Route über 192.168.50.2 und den Standard über 192.168.50.1 zeigen. Fehlt der Standard, haben Sie die Falle von oben reproduziert.
Testen Sie dann den echten Austausch
Routenverteilung ist nicht der ganze Weg. Das separate Gateway braucht weiterhin Weiterleitung, Eigentum an entfernten Peers und eine Zugriffsrichtlinie, die den Server erlaubt, und DHCP authentifiziert niemanden.
Halten Sie schließlich einen Rückbauplan bereit. Eine gelernte statische Route zieht sich nicht selbst zurück, wenn das VPN ausfällt, ein veralteter nächster Hop kann dieses Präfix also noch lange nach dem Verschwinden des Tunnels ins Leere laufen lassen.