Persistente Routen für ein Mac-VPN: networksetup oder ein Verbindungs-Hook?

Eine Route, die nach jeder Verbindung eingetippt wird, löst den Moment und nicht die Woche. Unter macOS ist die dauerhafte Wahl normalerweise ein Präfix, das beim VPN-Dienst gespeichert wird, weil der Dienst es bei jeder Verbindung neu installiert und entfernt, wenn der Dienst getrennt ist. Die Alternativen sind ein temporäres route add zum Testen und ein Verbindungs-Hook für Adressen, die erst nach der Aushandlung bekannt sind.

Entscheiden Sie, ob die Route zum Dienst oder zur Sitzung gehört

Fragen Sie, wovon das Präfix abhängt. Ist es ein festes privates Netz hinter einem nativen VPN-Dienst, gehört die Route zu diesem Dienst. Hängt es von einer Peer-Adresse ab, die sich bei jeder Verbindung ändert, kann ein Hook oder ein statusgesteuerter Job der bessere Eigentümer sein. Wenn Sie nur einen Pfad für die nächsten fünf Minuten prüfen, genügt eine temporäre Route.

Die dienstgebundene Route hat den saubersten Lebenszyklus. Sie erscheint mit dem Dienst und verschwindet, wenn der Dienst nicht verbunden ist, kann den Tunnel also nicht überleben, auf den sie zeigt. Diese Eigenschaft ist mehr wert als die Bequemlichkeit eines Einzeilers.

Eine sitzungsgebundene Route gehört zur Schnittstelle, und diese Nummer ändert sich ohne Vorankündigung. Eine Neuverbindung kann dem Tunnel einen anderen utun-Namen geben als die vorherige Sitzung, wodurch ein fest codierter Befehl zu einer Route wird, die ins Leere oder, schlimmer, auf einen anderen Tunnel zeigt.

Aktuellen Routen- und Dienststatus lesen

Beginnen Sie mit den Namen, die das System tatsächlich verwendet. Der Dienstname in den Netzwerkeinstellungen ist die Kennung für die folgenden Befehle, und die aktuelle Routentabelle zeigt, was der verbundene Client installiert hat. Lesen Sie beides, solange der Tunnel aktiv ist.

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

Diese Abfrage zeigt, welches Gateway und welche Schnittstelle der Kernel für diese Adresse in diesem Moment wählen würde. Wählt er bereits den Tunnel, ist das Präfix abgedeckt und eine neue Route wäre überflüssig. Wählt er den lokalen Router, fehlt dem Tunnel dieses Präfix.

Notieren Sie die Peer-Adresse, solange Sie verbunden sind. Sie wird zum Gateway-Wert in der dienstgebundenen Route und ist normalerweise das Ziel, das für die Standardroute des Tunnels in netstat -rn angezeigt wird.

Das Präfix mit networksetup speichern

Das Werkzeug networksetup hängt zusätzliche Routen an einen Netzwerkdienst. Für einen Dienst namens OfficeVPN und ein privates Präfix, das über den Tunnel-Peer erreicht wird, lautet die Form:

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

Jedes Tripel nach dem Dienstnamen gibt ein Ziel, seine Netzmaske und den Tunnel-Peer als Gateway an. Ein Aufruf kann mehrere Präfixe tragen, und ein leerer Aufruf löscht die gespeicherte Liste. Der Getter ist der Prüfschritt; ist die Liste leer, wurde der Satz nicht auf den Dienst angewendet, den Sie meinen.

Das Gateway muss der Tunnel-Peer sein, nicht der physische Router. Eine Route, die das lokale Gateway nennt, schickt das private Präfix über die physische Schnittstelle hinaus, was der ursprüngliche Fehler mit zusätzlichen Schritten ist. Ein veralteter Peer ist der häufigste Grund, warum eine korrekt aussehende Route nie Verkehr trägt. Lesen Sie den Peer aus dem verbundenen Zustand neu, statt eine Adresse aus einer alten Notiz zu kopieren.

route add nur für einen Test verwenden

Eine direkte Route ist nützlich, um zu beweisen, dass ein Präfix funktioniert, bevor Sie es dauerhaft machen. Die Schnittstellenform vermeidet eine Gateway-Abfrage:

sudo route -n add -net 10.20.0.0/16 -interface utun4

Die Route verschwindet bei der nächsten Neuverbindung und hängt von der Schnittstellennummer ab, die heute existiert. Das macht sie zu einer Diagnose, nicht zu einem Deployment. Wenn der Test funktioniert und die dienstgebundene Route nicht, vergleichen Sie zuerst den Gateway-Wert; das ist das Feld, das am häufigsten falsch ist.

Seien Sie vorsichtig mit Ratschlägen, die die Standardroute des VPN ersetzen, um Split-Verhalten zu erzwingen. Ein Client, der einen vollständigen Tunnel erzwingt, kann seine Routen nach einer Neuverbindung oder einer Richtlinienaktualisierung neu installieren, sodass die manuelle Änderung still rückgängig gemacht wird. Ein paar private Präfixe sind ein Routingproblem; den gesamten Internetverkehr gegen eine Full-Tunnel-Richtlinie lokal zu halten, ist eine Entscheidung auf der Serverseite.

Wählen Sie einen Hook nur, wenn die Adresse ausgehandelt wird

Für PPP-basierte Verbindungen wie L2TP führt macOS /etc/ppp/ip-up aus, sobald die Verbindung steht. Das Skript erhält den Schnittstellennamen und die ausgehandelten lokalen und entfernten Adressen, sodass es eine Route hinzufügen kann, die vom Peer abhängt, den der Server zugewiesen hat. Genau das ist der Fall, den eine feste Dienstroute nicht ausdrücken kann.

IKEv2 und Herstellerclients nutzen diesen PPP-Pfad möglicherweise gar nicht, was bedeutet, dass das Skript die gesamte Sitzung über schweigen kann. Wenn das passiert, ist ein launchd-Job, der scutil --nc status abfragt und auf eine Statusänderung reagiert, der gleichwertige Mechanismus, mit einer kleinen Verzögerung.

Welchen Hook Sie auch verwenden, machen Sie ihn idempotent und lassen Sie ihn nur Routen entfernen, die er selbst erstellt hat. Ein Skript, das jede Route löscht, die den Tunnel erwähnt, wird irgendwann die Route löschen, die den VPN-Server erreichbar hält, und die Verbindung bricht ab, sobald sie gelingt.

Prüfen Sie zum Schluss das private Ziel, normales Browsen und einen Neuverbindungs- oder Schlafzyklus. Untersuchen Sie dann scutil --dns, denn die Namensauflösung ist eine eigene Richtlinie, und eine funktionierende Route beweist nicht, dass die privaten Namen aufgelöst werden.