Private Routen behalten und die Umleitung verwerfen: OpenVPN-Split-Tunnel

Der Tunnel kommt hoch, die Anwendung lädt, und dann beginnt alles andere auf dem Laptop, sich merkwürdig zu verhalten. Das ist die übliche Form einer reinen Privat-Policy, die durch Löschen einer Zeile umgesetzt wird. Das Entfernen einer gepushten Standardroute ändert zwar, wohin der Verkehr geht, sagt aber nicht, wohin er stattdessen gehen soll, und berührt die Namensauflösung überhaupt nicht. Eine Policy braucht zwei positive Hälften, bevor sie getestet werden kann.

Die Umleitung zu löschen ist nur die halbe Änderung

Eine Full-Tunnel-Umleitung und eine reine Privat-Policy unterscheiden sich darin, was sie über die Welt behaupten. Die Umleitung beansprucht jedes Ziel, während die Privat-Policy eine Liste beansprucht und den Rest in Ruhe lässt. Den Anspruch zu löschen, ohne die Liste zu schreiben, erzeugt einen Client, der nichts außerhalb des LAN erreicht, was eher wie ein Routingfehler als wie eine Lücke in der Policy aussieht. Schreiben Sie die Liste, bevor Sie den Anspruch entfernen, und die Reihenfolge dieser beiden Schritte spielt keine Rolle mehr.

Beide Hälften sind Anforderungen und keine Vorgaben. Private Präfixe müssen in den Tunnel gelangen, und gewöhnliche Ziele müssen den Weg behalten, den sie vor der Verbindung hatten.

Wenn eine Organisation den Full-Tunnel vorschreibt, gilt nichts davon. Das reine Privat-Design gehört zu Umgebungen, in denen Split-Routing genehmigt ist.

pull-filter ist ein Treffer, kein Schalter

Die Direktive pull-filter entfernt gepushte Optionen, deren Namen zu einem Präfix passen, und mehr tut sie nicht. Wird die Umleitung ignoriert, bleibt jede andere gepushte Option bestehen, was normalerweise gewünscht ist: Routen, DNS-Einstellungen und der Route-Gateway-Wert kommen weiterhin an. Sie kann auch keine Direktive entfernen, die im lokalen Profil steht, weil die Filterung auf das wirkt, was der Server pusht.

Widerstehen Sie der Versuchung, jede Option zu ignorieren, die mit route beginnt. Dieses Muster verwirft auch die privaten Routen, die die Verbindung braucht, und es kann Gateway-Informationen verlieren, von denen der Tunnel abhängt.

route-nopull ist eine weitreichendere Entscheidung, als es aussieht. Es hindert den Client daran, gepushte Routen und DHCP-artige Optionen als Gruppe zu übernehmen, was eine andere Policy ist als das Herausfiltern einer einzelnen Option.

Schreiben Sie die Routenliste von der Anwendung nach außen

Beginnen Sie mit dem, was der Nutzer tatsächlich öffnet, und ergänzen Sie dann die begleitenden Teile. Eine Anwendung unter 10.60.20.15 impliziert ihr Subnetz 10.60.0.0/16, und ein privater Name impliziert den Resolver, der ihn beantwortet. Ein Nutzer, der eine Anwendung angefordert hat, braucht daher zwei Ziele und eine DNS-Entscheidung. Alles jenseits dieser Liste ist konstruktionsbedingt außerhalb des Geltungsbereichs, und genau das hält die Policy überprüfbar.

Auf einem kooperierenden Server werden daraus zwei gepushte Routen, und keine davon ist eine Umleitung. Behalten Sie die Tunnel-Topologie und die Route-Gateway-Werte bei, die der bestehende Dienst liefert.

Wenn nur einige Nutzer diese Policy brauchen, wenden Sie sie pro Client oder pro Gruppe an. Das Routing aller zu ändern, um die Anforderung eines Teams zu erfüllen, ist der Weg, auf dem ein Split-Tunnel zum Ausfall wird.

Lassen Sie DNS denselben Weg nehmen

Eine Route zum Resolver ist keine Resolver-Policy. Auf einem systemd-resolved-Client ist das semantische Ergebnis eine Routing-Domäne für den privaten Namensraum, die auf den internen Resolver zeigt, und das sorgt dafür, dass nur diese Namen ihn nutzen. Ein Windows-Client braucht stattdessen einen eigenen Mechanismus für Namensraum-Policies. Eine DNS-Server-Zeile im Profil installiert beides nicht von selbst.

Prüfen Sie, was das Betriebssystem ausgewählt hat, statt was das Profil angefordert hat. Unter Linux zeigt resolvectl status die Domäne und den Server pro Verbindung; unter Windows ist die Namensraum-Policy-Tabelle der gleichwertige Nachweis.

Halten Sie den Resolver durch den Tunnel erreichbar, sonst zeigt die Policy auf eine Adresse, die nicht abgefragt werden kann. Eine Resolver-Adresse, die der Tunnel nicht erreicht, verwandelt eine funktionierende Policy in eine Zeitüberschreitung.

Prüfen Sie beide Hälften bei einer Neuverbindung

Verbinden Sie den Client nach der Änderung erneut und prüfen Sie die effektive Route zu einer privaten und zu einer öffentlichen Adresse. Lösen Sie dann einen privaten und einen öffentlichen Namen auf und bestätigen Sie, dass jeder den vorgesehenen Resolver benutzt hat. Dass eine öffentliche Website lädt, beweist nur die zweite Hälfte, und das ist die Hälfte, die meist zufällig funktioniert.

Halten Sie die fertige Policy in einem Satz fest: Diese Präfixe und Namen nutzen diese Verbindung, alles andere folgt dem lokalen Weg. Bewahren Sie sie dann im Profil auf, statt nach jeder Anmeldung Adaptereinstellungen zu reparieren.