Mac L2TP-Split-Routen: Warum eine Host-Adresse nicht funktioniert

Die VPN verbindet, die Menüleiste zeigt es, und ein interner Host läuft trotzdem in einen Timeout. In dieser Situation gibt es drei mögliche Ursachen, und welche gilt, hängt davon ab, wie der Tunnel konfiguriert wurde. Entweder hat der Routenbefehl eine Host-Adresse verwendet, wo eine Netzwerkadresse nötig war, oder das Profil selbst installiert eine Standardroute, die die Entscheidung verschluckt, oder der Client ist ein PPP-Tunnel, der einen Hook statt eines Profilschlüssels braucht. Prüfen Sie sie in dieser Reihenfolge, denn die erste ist am billigsten auszuschließen.

Das Ziel ist eine Netzwerkadresse, die Maske beschreibt das Präfix

networksetup -setadditionalroutes nimmt Tripel aus Ziel, Subnetzmaske und Gateway. Der Aufruf, der ein internes Subnetz durch den Tunnel schickt, sieht so aus:

sudo networksetup -setadditionalroutes "VPN (L2TP)" 192.168.1.0 255.255.255.0 10.2.0.0

Beachten Sie, was das Ziel ist: die Netzwerkadresse, nicht die Adresse des Servers, den Sie erreichen wollen. In dem Fall, der diesen Artikel hervorbrachte, tat der identische Befehl mit 192.168.1.20 an dieser Stelle nichts Nützliches, und das Ersetzen durch 192.168.1.0 funktionierte sofort. Gleiche Maske, gleiches Gateway, eine andere Zahl. Das ist der ganze Fehler im Kleinen.

Der Grund ist Arithmetik, nicht Politik. Eine Host-Adresse mit einer /24-Maske beschreibt nicht 192.168.1.0/24; sie beschreibt etwas, das die Routentabelle nicht sinnvoll halten kann, also wird der Eintrag abgelehnt oder ignoriert, und der Tunnel trägt am Ende weniger, als Sie beabsichtigt hatten.

Wenn Sie genau einen Host wollen, verwenden Sie die Host-Adresse mit einer Maske von 255.255.255.255. Gemischte Paare sind der Punkt, an dem das schiefgeht, nicht die Verwendung einer Host-Adresse als solcher. Eine aus einer Adresse gebaute /32 ist eine legitime Route; eine aus einer Adresse gebaute /24 ist ein Fehler.

Der Aufruf ersetzt die Liste, und der Name ist wörtlich

Zwei Verhaltensweisen überraschen beim ersten Versuch. Der Befehl setzt die vollständige Liste zusätzlicher Routen, statt anzuhängen, sodass ein Aufruf, der ein Präfix hinzufügt, die anderen, die vorher da waren, still entfernt. Bauen Sie den ganzen Satz in einem einzigen Aufruf.

Der Dienstname ist auch nicht die Bezeichnung, die Sie sich ausgedacht haben. Lesen Sie ihn aus dem Werkzeug und kopieren Sie ihn exakt, einschließlich des Typ-Suffixes:

networksetup -listallnetworkservices

Ein Name, der sich um ein Zeichen unterscheidet, erzeugt keinen lesenswerten Fehler und keine Route. Kopieren und Einfügen ist hier die richtige Technik, nicht das Abtippen aus dem Gedächtnis.

Wenn das Profil die Standardroute beansprucht

Split-Routen verlieren gegen eine Standardroute für jedes Ziel, das sie nicht ausdrücklich abdecken, und ein L2TP-Profil, das für einen vollen Tunnel konfiguriert ist, installiert genau das. Wenn das Profil sagt, alles gehe durch den Tunnel, ändert sich die Liste der Zusatzrouten sehr wenig. Ihr Eintrag ist nicht falsch; er ist einfach irrelevant für die Ziele, die er nie benennt. Die Steuerung dafür sitzt meist in der Einstellung des Profils zum Senden des gesamten Verkehrs und nicht in irgendeinem Routenbefehl.

Entscheiden Sie, welches Modell Sie wirklich wollen, bevor Sie weitere Einträge bearbeiten. Voller Tunnel mit Ausnahmen ist eine andere Konfiguration als Split-Tunnel mit bestimmten Präfixen, und beides zu mischen erzeugt eine Tabelle, die niemand vorhersagen kann.

Wenn die Organisation einen vollen Tunnel verlangt, hören Sie auf, ihn lokal aufzuteilen, und tragen Sie die Anforderung zu dem, der die Richtlinie besitzt. Eine lokal hinzugefügte Route, die ihr widerspricht, wird ohnehin beim nächsten Profil-Update entfernt.

PPP-Tunnel brauchen einen Hook statt eines Schlüssels

Bei PPP-basierten Tunneln ist defaultroute der Profilschlüssel, der eine Standardroute erzeugt; entfällt er, beansprucht der Client nicht mehr jedes Ziel. Routen werden dann hinzugefügt, nachdem die Schnittstelle erscheint, üblicherweise aus /etc/ppp/ip-up:

#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0

Halten Sie das Skript im Besitz von root und ausführbar, und fügen Sie eine Absicherung auf den Schnittstellennamen hinzu, wenn mehr als ein Tunnelprofil auf der Maschine existiert. Ein Hook, der für jede PPP-Verbindung läuft und einen Gerätenamen annimmt, ist ein kleiner Fehler mit langem Leben.

Prüfen Sie die Aufteilung mit drei Anfragen

Erfassen Sie die Tabelle, während Sie verbunden sind, und notieren Sie, welche Schnittstelle den Tunnel bedient. Prüfen Sie dann das konkrete Ziel, statt dem Exit-Status des Befehls zu vertrauen, der es angelegt hat. Ein Exit-Code meldet, ob das Werkzeug die Argumente akzeptiert hat, nicht ob der Verkehr den beabsichtigten Weg nimmt.

Schließen Sie mit drei Anfragen ab, die die Aufteilung beweisen: ein interner Host per Adresse, ein interner Name über den internen Resolver und eine öffentliche Seite, die weiterhin die lokale Verbindung nutzen sollte. Wenn die öffentliche Seite jetzt ebenfalls durch den Tunnel läuft, hat die Aufteilung nie stattgefunden, was die Routenliste auch zu sagen scheint.

Verbinden Sie sich noch einmal und wiederholen Sie die interne Anfrage, denn von Hand hinzugefügte Routen können die Schnittstelle überleben, die sie gültig gemacht hat und den Verkehr nach dem Abfall des Tunnels still in ein schwarzes Loch schicken.