OpenVPN pull-filter trifft mehr als nur die gemeinte Route

Sie fügen eine Zeile hinzu, um Ihre lokale Standardroute zu behalten, und danach erreicht der Tunnel den internen DNS-Server nicht mehr. Die Zeile war pull-filter ignore "route", was nicht "ignoriere diese Route" bedeutet. Es bedeutet "verwirf jede gepushte Option, deren Text mit diesen fünf Buchstaben beginnt", und auf einem normalen Server schließt das route-gateway, route-metric und route-ipv6 zusammen mit den Routen selbst ein. Die Checkliste unten ist das, was ich durchgehe, bevor ich ein Profil anfasse, das jemand anderes benutzen muss.

Der Filter gilt nur für gepushte Optionen

pull-filter wirkt auf die Optionszeilen, die der Server nach dem Aufbau des Tunnels sendet, und auf nichts anderes. Optionen in Ihrer lokalen Datei werden davon nicht berührt, Anwendungsverkehr ebenso wenig. Wenn Sie hofften, einen Prozess an der Nutzung des Tunnels zu hindern, ist dies das völlig falsche Werkzeug, und keine Filterkombination wird das leisten.

Dieser Geltungsbereich ist nützlich, denn er bedeutet, dass Sie die Serverkonfiguration in Ruhe lassen und trotzdem einen Teil davon lokal ablehnen können. Es ist auch eine Grenze, die im Ticket erwähnt gehört: Ein Filter ändert, was dieser Client akzeptiert, nicht was der Server anbietet. Er hat keine Wirkung auf andere Nutzer desselben Profils. Er übersteht auch keinen Wechsel zu einem anderen Client, der die Option nicht implementiert, was man wissen sollte, bevor man einen Workflow darauf aufbaut.

Bestätigen Sie, was der Server tatsächlich sendet, bevor Sie das Muster schreiben. Bei hoher Ausführlichkeit gibt der Client die empfangene Zeichenkette der gepushten Optionen aus, und dies ist die einzige ehrliche Quelle für den genauen Text, gegen den Sie abgleichen:

sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn

Lesen Sie die gepushte Zeile als Liste von Optionen, getrennt durch Kommas, und beachten Sie, dass Optionsnamen und ihre Argumente durch Leerzeichen getrennt sind. Ihr Filtertext wird mit diesem Strom verglichen, weshalb Leerzeichen im nächsten Schritt so wichtig sind.

Der Abgleich ist ein Präfix, also entscheiden die Leerzeichen

Der Vergleich ist ein Zeichenkettenpräfix, kein geparster Optionsname. Daher trifft "route" auf route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 und route-metric 100 zu. Ein zusätzliches Leerzeichen am Ende engt ihn auf die Familie ein, die Sie wahrscheinlich meinten, und das vollständige Präfix engt ihn weiter auf ein konkretes Ziel ein.

Die letzte Zeile ist die, die Leute bei Split-Tunnel-Arbeit erwischt. Den eigenen Resolver zu behalten ist eine legitime Wahl, und sie bedeutet, dass jeder interne Name nun von einem Resolver abhängt, der die private Zone nicht sieht. Das ist eine Folge, die man bewusst akzeptiert, kein Nebeneffekt, den man in der Produktion entdeckt.

Präfix-Abgleich bedeutet auch, dass eine Regel sich später still erweitern kann. Wenn der Server eine neue Option hinzufügt, die mit Ihrem Text beginnt, beginnt Ihr Filter darauf anzuwenden, ohne dass jemand Ihr Profil bearbeitet. Das ist das Fehlermuster, gegen das man entwerfen muss, und die Abhilfe ist, so viel der Option wie möglich abzugleichen statt so wenig wie möglich.

Drei Verben mit drei verschiedenen Ergebnissen

accept, ignore und reject sind nicht drei Schreibweisen derselben Idee. Sie unterscheiden sich darin, was der Client bei einem Treffer tut und ob jemand davon erfährt.

ignore verwirft die passende Option still, was Sie für eine Einstellung wollen, die Sie bewusst ersetzt haben. reject verwirft sie und lässt den Client sich beschweren, was Sie wollen, wenn ihre Abwesenheit im Protokoll sichtbar sein soll statt später entdeckt zu werden. accept ist die positive Form, verwendet, wenn Sie eine Erlaubnisliste aufbauen statt einzelne Optionen zu entfernen.

Welches Verb Sie auch verwenden, die Filter werden in der Reihenfolge ihres Auftretens angewendet, sodass zwei überlappende Regeln ein reihenfolgeabhängiges Ergebnis erzeugen, das sehr schwer zu prüfen ist. Halten Sie eine Regel pro Absicht und setzen Sie den spezifischsten Text in jede. Wenn Sie eine Erlaubnisliste brauchen, ziehen Sie wenige accept-Regeln einer Menge ignore-Regeln vor, die dasselbe ergeben. Prüfer können die Datei dann von oben nach unten lesen und das Ergebnis vorhersagen, und das ist der einzige Test, der skaliert.

Prüfen Sie die angewandte Route und den Resolver, nicht das Profil

Ein Filter, der in der Datei korrekt aussieht, kann Sie immer noch mit einem Tunnel zurücklassen, der nichts Nützliches routet. Prüfen Sie die Wirkung auf dem laufenden System, wo gepushte Optionen bereits angewendet oder verworfen wurden:

ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/

Die ersten beiden Zeilen sagen Ihnen ob die gepushte Standardroute angekommen ist und wie viele statische Einträge überlebt haben. Die Resolver-Abfrage zeigt, welchen Server die Tunnel-Schnittstelle tatsächlich verwendet, und dort zeigt sich meist eine DNS-Überraschung. Die letzte Zeile beantwortet die einzige Frage, die für einen Nutzer zählt.

Testen Sie beide Richtungen, solange Sie dort sind. Eine Regel, die Ihr lokales Internet funktionsfähig hält, aber die interne Namensauflösung still bricht, besteht eine oberflächliche Prüfung und scheitert an der ersten echten Aufgabe, also nehmen Sie eine interne Ressource und eine öffentliche Website in denselben Test auf.

Dokumentieren Sie die Ausnahme und wer sie besitzt

Ein Filter ist eine Ausnahme vom Entwurf des Betreibers, also schreiben Sie ihn mit Begründung und Prüfpunkt auf. "Ignoriert gepushte Routen, um die lokale Standardroute zu behalten" ist prüfbar; eine nackte Zeile in einem Profil nicht, und die nächste Person wird sie löschen oder per Vermutung erweitern.

Auch die Version zählt hier. Das Abgleichverhalten und die genaue akzeptierte Syntax wurden über OpenVPN 2.4, 2.5 und 2.6 verfeinert, daher bestätigen Sie das Muster anhand des Handbuchs für den Build, den Sie ausliefern, und nicht anhand eines Forumsbeitrags über eine ältere Version. Das OpenVPN 2.6-Handbuch dokumentiert die Option und ihre Abgleichregel.

Schließlich stimmen Sie die Ausnahme mit demjenigen ab, der den Server betreibt. Ein clientseitiger Filter, der einer bewussten Serverrichtlinie widerspricht, ist ein Support-Vorfall, der auf das nächste Audit wartet, und es ist viel billiger, ihn zu klären, bevor das Profil ausgeliefert wird, als nachdem jemand bemerkt, dass die Routen fehlen.