OpenVPN-Engine oder Tunnelblick: Wem gehört die Mac-VPN-Sitzung?

Homebrew installiert ein OpenVPN-Programm; Tunnelblick installiert einen Manager, der eine oder mehrere Engines ausführt. Das sind verschiedene Ebenen, und die nützliche Frage ist nicht, ob Sie gern ein Terminal benutzen. Sie lautet, wem die Konfiguration, die DNS-Änderungen, die Abfrage der Anmeldedaten und das Aufräumen beim Ende der Sitzung gehören. Ein einziger Eigentümer für diese Ebenen macht die Einrichtung vorhersehbar.

Gehen Sie die fünf Prüfungen unten der Reihe nach durch. Die erste, bei der es zwei Eigentümer gibt, erzeugt die seltsamen halbverbundenen Zustände, die Leute dem OpenVPN selbst anlasten. Jede Prüfung nennt den Beleg, der sie entscheidet.

Prüfung eins: Welche OpenVPN-Binärdatei tatsächlich läuft

Führen Sie pgrep -fl openvpn im verbundenen Zustand aus und lesen Sie die vollständige Befehlszeile. Der erste Pfad ist die Engine, die tatsächlich läuft. Auf Apple Silicon liegt eine Homebrew-Installation normalerweise unter /opt/homebrew, während Intel-Macs /usr/local verwenden, und Tunnelblick führt eine Engine aus seinem eigenen Anwendungspaket aus.

Tunnelblick bündelt Engines und lässt eine Konfiguration eine davon auswählen. Das Aktualisieren der Homebrew-Formel ändert die eigenständige Binärdatei, nicht die Engine, die ein Tunnelblick-Profil startet. Wenn Sie Versionen vergleichen, um einen Verhaltensunterschied zu erklären, vergleichen Sie die Engine in der Prozessliste statt der im Paketmanager. Die Versionszeichenfolge allein sagt Ihnen nicht, welches Profil diese Engine geladen hat.

Ein kopiertes Profil kann zwei Engines auch identisch aussehen lassen, während sie verschiedene Dateien lesen. Der Profilpfad in der Befehlszeile sagt Ihnen, welche Konfiguration der laufende Prozess geladen hat; ein im Editor geöffnetes Profil ist kein Beleg. Vergleichen Sie diesen Pfad, bevor Sie Verhalten vergleichen.

Prüfung zwei: Wer DNS und Routen ändert

Die Engine kann OpenVPNs eigene up- und down-Direktiven ausführen, aber der Manager kann denselben Lebenszyklus besitzen. Die Nameserver-Einstellungen von Tunnelblick steuern seine Standard-Verbindungs- und Trennskripte, und wenn diese Integration aktiviert ist, können konkurrierende Direktiven im Profil ignoriert werden.

Das ist wichtig, weil DNS der Ort ist, an dem ein funktionierender Tunnel am häufigsten defekt aussieht. Prüfen Sie scutil --dns im verbundenen Zustand, notieren Sie, welcher Resolver zuerst kommt, und bestätigen Sie, dass er nach dem Trennen zurückkehrt. Wenn das Profil erwartet, DNS selbst zu setzen, während der Manager es auch verwaltet, verliert einer von beiden.

Entscheiden Sie vor der ersten Verbindung, welche Ebene DNS besitzt, und entfernen Sie dann die verlierende Direktive, statt beide stehen zu lassen. Routenänderungen folgen derselben Regel: ein Eigentümer, in der Konfiguration sichtbar, mit einem dokumentierten Wiederherstellungspfad.

Prüfung drei: Woher die Anmeldedaten kommen

Eine interaktive Abfrage und ein unbeaufsichtigter Prozess haben unterschiedliche Anforderungen. Anmeldedaten, die eine Anwendung speichert, sind nicht automatisch für einen anderen Prozess verfügbar, und ein auf den Manager beschränkter Schlüsselbund-Eintrag kann für eine eigenständige, aus einer Shell gestartete Engine unsichtbar sein.

Listen Sie die Quelle der Anmeldedaten für das Profil auf: ein Client-Zertifikat und einen Schlüssel, eine Abfrage von Benutzername und Passwort oder ein Token von einem externen Helfer. Bestätigen Sie dann, dass der gewählte Eigentümer diese Quelle ohne Menschen erreichen kann, wenn die Verbindung einen Neustart überleben soll.

Prüfung vier: Wer den Prozess startet, überwacht und stoppt

Eine eigenständige Bereitstellung braucht einen Supervisor, wenn sie aktiv bleiben soll. Launchd kann die Engine beim Anmelden oder auf Anforderung starten, sie nach einem Absturz neu starten und sauber stoppen, aber jemand muss diesen Job schreiben und besitzen. Den Befehl in einem Terminal auszuführen funktioniert für einen Test und nicht für einen Benutzer, der das Fenster schließt.

Wenn Tunnelblick der Eigentümer bleibt, verwenden Sie dessen unterstützte Steuerelemente, statt eine zweite Engine zu starten. Die Homebrew-Binärdatei startet mit einem kopierten Profil eine unabhängige Verbindung mit eigener Konfiguration und eigenem Integrationskontext, statt die bestehende Tunnelblick-Sitzung zu befehligen.

Welchen Eigentümer Sie auch wählen, definieren Sie, was bei Ruhezustand, Netzwerkwechsel und Abmeldung passiert. Ein Manager behandelt diese Ereignisse normalerweise; ein nackter Prozess meist nicht, und die daraus resultierende veraltete Route oder der Resolver lässt sich leicht als Serverfehler fehldeuten.

Prüfung fünf: Wie die Übergabe überprüft wird

Testen Sie den neuen Eigentümer mit deaktiviertem alten und testen Sie den alten danach erneut, wenn Sie ihn behalten wollen. Eine private Ressource, die unter einem Arbeitsablauf antwortet und unter dem anderen nicht, ist ein Beleg für die fehlende Integration, nicht für den Server.

Notieren Sie für eine Übergabe an eine eigenständige Engine den Profilpfad, den Binärpfad, den Supervisor, den DNS-Eigentümer und die Quelle der Anmeldedaten. Prüfen Sie dann in dieser Reihenfolge die private Ressource, den Weg ins öffentliche Internet und ein sauberes Trennen. Wenn DNS oder Routen nach dem Trennen bleiben, ist der neue Eigentümer nicht fertig.

Wählen Sie für eine Übergabe an Tunnelblick die Engine für die Konfiguration, aktivieren Sie die gewünschte DNS-Integration und entfernen Sie Profildirektiven, die ihr entgegenstehen. Wiederholen Sie dann dieselben drei Prüfungen. Eine Verbindung, die funktioniert, aber den Resolver verändert zurücklässt, ist eine gescheiterte Übergabe, selbst wenn der Tunnel hochkam.

Verpackung entscheidet nicht über Serverkompatibilität. Prüfen Sie die eigenen Client-Anforderungen des Dienstes und wählen Sie die Engine allein nur dann, wenn Sie ihre Verwaltung bereitstellen wollen.