So testen Sie einen zweiten VPN-Client auf einem Mac, ohne den ersten zu verlieren

Sie installieren den zweiten Client zum Vergleich, und der erste funktioniert nicht mehr. Nichts wurde gelöscht, und beide Anwendungen sind weiterhin installiert. Verändert hat sich das, was darunter liegt: eine Systemerweiterung, eine DNS-Einstellung oder eine Standardroute, und die beiden Clients sind sich nun uneinig, wem sie gehört. Die Installation ist nicht der riskante Teil; riskant ist, beide ohne eine festgehaltene Ausgangslage zu betreiben, zu der Sie zurückkehren können.

Das Symptom: Die funktionierende Einrichtung endet nach der zweiten Installation

Moderne macOS-VPN-Clients liefern häufig eine Netzwerkerweiterung statt einer Schnittstelle alten Stils. Die Installation einer solchen kann eine Freigabe verlangen, ein Konfigurationsprofil hinzufügen oder eine Systemerweiterung registrieren, die den Datenverkehr beeinflusst, bevor überhaupt eine Verbindung aufgebaut wird. Die Erweiterung wird geladen, bevor das App-Fenster erscheint, weshalb der ursprüngliche Client scheitern kann, während der neue untätig bleibt.

Kann der ursprüngliche Client danach keine Verbindung herstellen oder verbindet er und löst nichts auf, ist die neue Erweiterung der erste Verdächtige. Das ist kein Beweis für einen Konflikt, aber hier beginnt die Untersuchung. Prüfen Sie als Nächstes die Erweiterungsliste und die installierten Konfigurationsprofile, nicht nur den Programme-Ordner.

Halten Sie die Ausgangslage fest, bevor Sie etwas installieren

Notieren Sie, was derzeit funktioniert: das Ergebnis der Anwendung, die Client-Version, den Endpunkt, mit dem sie sich verbindet, und alle Ausnahmen pro App oder für den geteilten Tunnel. Speichern Sie das ursprüngliche Profil über den geschützten Prozess, den der Client unterstützt, und nicht, indem Sie Dateien aus einem Anwendungspaket kopieren.

scutil --dns | head -40
netstat -rn | head -30
ifconfig | grep -E "^(utun|ipsec)"

Erfassen Sie diese drei Ausgaben, während der funktionierende Client verbunden ist. Sie liefern den Zustand des Resolvers, die Routing-Tabelle und die Schnittstellenliste, die eine funktionierende Einrichtung erzeugt, und genau das brauchen Sie für den späteren Vergleich. Wird der Mac von einem Arbeitgeber verwaltet, bestätigen Sie vor dem Start, dass der Vergleich erlaubt ist, denn eine automatische Arbeitsverbindung kann sich während des Tests wieder aktivieren, und das Ergebnis steht dann für keinen der beiden Clients allein. Bewahren Sie die drei Ausgaben neben der Profilnotiz auf, damit der spätere Vergleich eine Referenz hat.

Ändern Sie jeweils einen aktiven Pfad

Beenden Sie die ursprüngliche Verbindung über ihre normale Steuerung und starten Sie dann die Alternative. Zwei gleichzeitig verbundene Clients ergeben ein Ergebnis, das die Kombination beschreibt, nicht eines der Produkte. Halten Sie Endpunkt und Aufgabe vergleichbar, wenn die Dienste es zulassen, denn ein schnellerer Download über einen anderen Server vergleicht zwei Verbindungsoptionen und nicht zwei Anwendungen.

Scheitert der neue Client, bewahren Sie seinen ersten Fehler auf, bevor Sie etwas anderes ändern. Der erste Fehler benennt meist die Stufe, und ein zweiter Versuch nach einer Einstellungsänderung meldet oft etwas weniger Nützliches.

Vergleichen Sie DNS, Routen und die App, nicht nur die Geschwindigkeit

Führen Sie dieselben drei Befehle mit verbundenem neuem Client aus und vergleichen Sie sie Zeile für Zeile. Ein Resolver, der woanders hinzeigt, oder eine Routing-Tabelle ohne das private Subnetz erklärt die meisten Verhaltensunterschiede, bevor Sie den Durchsatz betrachten. Testen Sie dann die eigentliche Anwendung mit derselben Aufgabe, denn ein Client, der schnell verbindet und einen internen Namen nicht auflöst, hat den Vergleich nicht gewonnen, auch wenn das Statusfenster besser aussieht.

Notieren Sie, welche Schnittstelle der Datenverkehr genutzt hat. Unter macOS ist der Name der Tunnel-Schnittstelle kein verlässlicher Hinweis darauf, welcher Client die Route besitzt, also kombinieren Sie die Schnittstellenliste mit der Routing-Tabelle, statt nur eine davon zu lesen. Existieren zwei utun-Schnittstellen, ist diejenige mit passender Route und Resolver-Eintrag die, die Ihren Datenverkehr trägt. Aus dem Namen zu raten, führt dazu, dass die falsche Schnittstelle beschuldigt wird, denn die vorhandene Schnittstelle ist nicht immer die, die Datenverkehr trägt.

Lesen Sie die drei Ausgaben, statt sie nur zu überfliegen. Im Resolver-Dump zeigt ein Namensserver, der an eine utun-Schnittstelle gebunden ist, welcher Client ihn installiert hat; in der Routing-Tabelle nennt die Standardroute die Schnittstelle, die Datenverkehr trägt; in der Schnittstellenliste bedeutet ein zweites utun-Gerät, dass ein zweiter Tunnel erstellt wurde. Diese drei Zeilen trennen im Vergleich zur Ausgangslage eine wiederhergestellte Einrichtung von einer, in der beide Clients noch konkurrieren.

Stellen Sie wieder her, dann entfernen Sie sauber

Kehren Sie über den eigenen Ablauf des ursprünglichen Clients zurück und bestätigen Sie, dass die Ausgaben der Ausgangslage mit Ihren Notizen übereinstimmen. Erholt sich der Resolver oder die Routing-Tabelle nicht, halten Sie an und beheben Sie das, bevor Sie etwas anderes entfernen. Entfernen Sie die ungenutzte Einrichtung über die Komponente, der sie gehört: das Deinstallationsprogramm des Clients, das Profil oder die Einstellungen der Systemerweiterung.

Schließen Sie ab, indem Sie Ihre Notizen um die getestete Version, den verwendeten Endpunkt und das Ergebnis für jeden ergänzen. Ein halbes Jahr später ist diese Aufzeichnung der Unterschied zwischen einer Entscheidung und einem Gerücht.