Was bypass-dhcp einem OpenVPN-Routenplan tatsächlich hinzufügt

Das Flag installiert eine einzelne Host-Route zu einem DHCP-Server außerhalb des Tunnels. Es ist keine Internetweiterleitung, keine DNS-Richtlinie, keine IPv6-Abdeckung und keine Lösung für Mobilfunkprobleme.

Ein Profil mit redirect-gateway def1 bypass-dhcp verbindet eine IPv4-Standardrouten-Überschreibung mit einer einzigen engen Ausnahme. Viele lesen das letzte Wort und erwarten eine allgemeine Lösung für Mobilfunkverbindungen, dann verbringen sie einen Nachmittag mit einer DHCP-Theorie, die das Flag nie gestützt hat. Jeder Teil tut eine Sache, und die Ausnahme ist viel kleiner als ihr Ruf.

Zerlegen Sie die Flags, bevor Sie einen reinen Mobilfunkfehler der Adressvergabe zuschreiben. Die beiden Hälften dieser Zeichenkette haben nichts miteinander zu tun.

Zwei Flags, zwei unabhängige Aufgaben

Mit def1 fügt der Client zwei IPv4-Halb-Standardrouten hinzu, statt die bereits vorhandene Standardroute zu ersetzen. 0.0.0.0/1 deckt die untere Hälfte des Adressraums ab und 128.0.0.0/1 die obere, sodass beide zusammen jedes Ziel erreichen, während jede für sich spezifischer bleibt als 0.0.0.0/0. Die ursprüngliche Standardroute bleibt daher in der Tabelle, ohne diese Nachschlagen zu gewinnen, was das alte Gateway für alles erreichbar hält, was der Client ausdrücklich routet. Außerdem bleiben zwei überlappende Standardrouten in der Tabelle, weshalb ein Routenauszug seltsamer aussehen kann, als das Profil vermuten lässt.

bypass-dhcp ist getrennt und berührt die Standardroute überhaupt nicht. Das OpenVPN-2.6-Handbuch beschreibt es als Hinzufügen einer direkten Route zu einem DHCP-Server, der nicht im lokalen Subnetz liegt, sodass Lease-Verkehr außerhalb des Tunnels verläuft, und merkt an, dass das Verhalten auf Windows-Clients implementiert ist und anderswo möglicherweise nicht verfügbar ist.

Der Grund für seine Existenz ist mechanisch. Sobald die Halb-Standardrouten den ausgehenden Verkehr erfassen, würde eine DHCP-Erneuerung an einen Server im physischen Netzwerk in den Tunnel geroutet, wenn nicht etwas diese Adresse an die reale Schnittstelle bindet. Das Flag bindet sie.

Worauf die Ausnahme tatsächlich begrenzt ist

Eine beispielhafte Tabelle nach erfolgreicher Verbindung zeigt die Form: zwei Halb-Standardrouten durch den Tunnel und eine Host-Route für den DHCP-Server über das physische Gateway. Lesen Sie sie als Form, nicht als Ihre eigenen Adressen.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

Diese dritte Zeile nennt ein einziges Ziel. Sie ist keine Resolver-Einstellung, keine allgemeine Erlaubnis für das lokale Netzwerk und keine Egress-Regel auf dem Server. Ein Telefon an einem Mobilfunkträger hat möglicherweise keinen DHCP-Server, den der Client so identifizieren kann, weshalb das Flag dort nichts ändert.

Prüfen, was der Client wirklich installiert hat

Unterscheiden Sie zwischen einer im Profil geschriebenen Option, einer vom Server angebotenen Option und einer Route, die der Verbindungseigentümer tatsächlich angewendet hat. Ein Client, der ein nicht unterstütztes Flag ablehnt, kann den Rest der Konfiguration behalten, sodass der Tunnel hochkommt und die Ausnahme einfach fehlt. Lesen Sie das eigene Protokoll des Clients und die resultierende Routentabelle, statt anzunehmen, dass die Zeile in der Datei wirksam wurde. Drei davon können gleichzeitig zutreffen, und nur das letzte ändert, wohin Pakete tatsächlich gehen.

Halten Sie die Route zum VPN-Endpunkt gleichzeitig nutzbar. Diese Endpunkt-Ausnahme ist eine andere Anforderung als die DHCP-Ausnahme, und ohne sie kann der Tunnel den Transport erfassen, der ihn am Leben hält.

Prüfen Sie bei einem Anwendungsziel das effektive Nachschlagen in dem Kontext, in dem es fehlschlägt. Spezifischere lokale Routen, Policy-Routing und Ausnahmen pro Anwendung verändern alle die Antwort, daher ist das Vorhandensein zweier Halb-Standardrouten keine Bestandsaufnahme jedes Flusses.

Der Rest des Weges steckt nicht in diesem Flag

Der Server braucht weiterhin die Erlaubnis, den Internetverkehr des Clients weiterzuleiten, und eine Ausgangsregelung, die ihn zurückgeben kann. Keine clientseitige Route erzeugt fehlende Weiterleitung oder Quellübersetzung auf dem Server, und kein Flag ersetzt einen funktionierenden Rückweg.

Namensauflösung und IPv6 brauchen jeweils ihre eigene Richtlinie. Eine IPv4-Überschreibung richtet den Resolver weder auf einen Server auf der Tunnelseite noch stellt sie IPv6-Abdeckung her, und ein Client, der nur v4 umleitet, lässt einen v6-Pfad unberührt.

Vergleichen Sie eine genehmigte harmlose Anfrage über einen funktionierenden und einen fehlerhaften Zugangsweg, während Profil und Ziel gleich bleiben. Halten Sie fest, ob der Unterschied in der Namensauflösung, im Tunnelaufbau, in der Routenwahl oder im weitergeleiteten Verkehr liegt, und bewahren Sie die Antwort beim Profil auf. Dieser Eintrag ist es, der den Nächsten davon abhält, DHCP für ein Problem verantwortlich zu machen, das es nicht erreichen kann.

Ähnliche Artikel