VPN-Route unter macOS prüfen: route get ohne Änderungen

Ein Nutzer erreicht das Intranet im Büronetz und nicht durch den Tunnel, während die Einstellungen die VPN weiterhin als verbunden anzeigen. Die Routentabelle in diesem Moment zu bearbeiten riskiert, die Remotesitzung zu kappen, mit der Sie diagnostizieren. Fragen Sie stattdessen den Kernel, welchen Pfad er für den fehlschlagenden Host wählen würde. Das macOS-Werkzeug route hat eine get-Operation, die genau das für ein Ziel beantwortet, ohne etwas zu ändern.

Fragen Sie den fehlschlagenden Host ab, nicht die Standardroute

Ein Screenshot der Standardroute sagt auf einem modernen Mac sehr wenig, weil ein spezifischeres Ziel oder eine eingeschränkte Policy überstimmen kann, was die Standardroute zu sagen scheint. Der Tunnel kann stehen, die Standardroute kann korrekt aussehen, und der eine Host, den Sie brauchen, kann trotzdem woandershin geroutet werden. Fragen Sie die Adresse ab, die fehlschlägt, und lassen Sie den Kernel den gewählten Pfad benennen.

Die Form ist route -n get gefolgt von der Adresse: route -n get 203.0.113.10, wobei die Dokumentationsadresse für Ihr Ziel steht. Verwenden Sie das autorisierte Ziel und die passende Adressfamilie, denn eine IPv4-Antwort sagt nichts über eine Ressource aus, die nur IPv6 spricht. Die Dokumentation des route-Werkzeugs beschreibt die get-Operation und die Felder, die sie ausgibt.

Lesen Sie Interface und Gateway als Beweis

Führen Sie die Abfrage vor dem Verbinden der VPN aus und danach noch einmal, und vergleichen Sie die Zeilen für Interface und Gateway. Die Differenz zwischen diesen beiden Antworten ist das, was der Tunnel tatsächlich geändert hat, und sie ist weit nützlicher als ein vollständiger Tabellenauszug. Ist das Interface in beiden Läufen identisch, war die Route nie das Problem, und Sie können aufhören, das Routing zu betrachten.

Notieren Sie Ziel, Interface, Gateway und den Zeitpunkt der Abfrage, bevor Sie eine Schlussfolgerung ziehen. Die Ausgabe ist Beweis, keine Diagnose: dasselbe Interface kann für einen Host richtig und für einen anderen falsch sein, wenn ein Split-Tunneling im Spiel ist.

Eine korrekte Route ist keine funktionierende Anfrage

Eine Route sagt Ihnen, welches Interface der Kernel verwenden würde, mehr nicht. DNS, eine Host-Firewall und die Autorisierung der Anwendung stehen alle über dieser Entscheidung, und die Anfrage kann fehlschlagen, nachdem das Routing gelungen ist. Bewahren Sie das genaue Symptom, bevor Sie weitermachen, denn "keine Verbindung" und "verbindet, liefert aber einen Fehler" sind verschiedene Untersuchungen mit verschiedenen nächsten Schritten. Die Resolver-Ansicht und die Interface-Ansicht ergänzen die Zielabfrage, statt sie zu ersetzen.

Ein Auszug der Routing-Tabelle hat weiterhin seinen Platz: So bemerken Sie eine unerwartete Standardroute. Eine verbliebene gewöhnliche Standardroute beweist nicht, dass die VPN ungenutzt ist, weil spezifischere Einträge über sie gewinnen.

Halten Sie Endpunkt und Ressource auseinander

Es sind zwei Nachschlagevorgänge im Spiel, und sie beantworten verschiedene Fragen. Den Endpunkt zu erreichen ist eine äußere Reise über das physische Netz. Die Anwendung zu erreichen geschieht im Tunnel, an einer Adresse, die nur auf der privaten Seite existiert. Beides zu verwechseln erzeugt die klassische falsche Schleife, in der der Endpunkt durch den Tunnel zu routen scheint, den er beendet. Fragen Sie beide Adressen getrennt ab, beschriften Sie jedes Ergebnis, und die Verwirrung verschwindet.

Präfix-Überlappung ist der andere Fall, den man kennen sollte. Wenn sich lokale und entfernte Bereiche überlappen, entscheidet das längste Präfix, sodass ein überlappendes lokales Subnetz die erwartete entfernte Adresse beschatten kann. Das private Ziel sieht dann identisch mit einem lokalen aus, und die Korrektur gehört in den Adressplan statt in die Routentabelle. Die get-Abfrage zeigt, welches Interface gewonnen hat, und das ist die Tatsache, die Sie vor jeder Änderung brauchen.

Erst lesen, später ändern

Halten Sie route add und route delete aus dem ersten Durchgang heraus. Auf einem Mac, den Sie remote administrieren, kann eine unachtsame Tabellenänderung genau den Weg zurück zur Maschine nehmen und niemanden zurücklassen, der die Diagnose beenden kann. Entscheiden Sie, welche Route korrekt ist, schreiben Sie auf, wie die Änderung rückgängig gemacht wird, und führen Sie sie erst dann aus. Eine Inspektion hat keinen solchen Schwanz.

Dieselbe Vorsicht gilt für das Leeren von Caches und den Neustart von Netzwerkdiensten als ersten Schritt, weil beides den Beweis zerstört, den Sie gerade lesen wollten. Nur-Lese-Prüfungen sind billig, wiederholbar und in beliebiger Reihenfolge sicher. Machen Sie sie zum Standard, und greifen Sie nur dann zu einer Änderung, wenn der Beweis darauf zeigt.