OpenConnect unter macOS: Paket, Release-Archiv oder git-Klon

Drei Wege bringen einen OpenConnect-Client auf einen Mac, und sie hinterlassen unterschiedliche Dinge auf der Platte. Eine Homebrew-Formel installiert eine kompilierte Binärdatei plus das Netzwerkskript, das Routen und DNS einrichtet. Ein Release-Archiv liefert Quellcode mit einem erzeugten Buildsystem. Ein git-Checkout liefert Quellcode ohne eines. Die falsche Wahl ist der Grund, warum Leute wenige Minuten nach Beginn einer Anleitung auf ein fehlendes configure stoßen.

Zwei verschiedene Maschinen unter demselben Namen

Der Paketweg ist ein einziger Befehl und die richtige Voreinstellung für jeden, dessen Aufgabe das Verbinden statt das Entwickeln ist.

brew install openconnect

Was dabei installiert wird, ist wichtiger als der Befehl. Man bekommt die Binärdatei des Clients und außerdem ein vpnc-script, das der Client aufruft, um Schnittstelle, Routen und Resolver zu programmieren. Beide arbeiten als Paar: Die Binärdatei beendet die TLS-Sitzung und übergibt die entstandene Schnittstelle an das Skript, und das Skript ist der Teil, der weiß, wie dieses Betriebssystem sein Netzwerk verändert haben will.

Diese Trennung erklärt eine ganze Klasse verwirrender Berichte. Ein Client, der sich verbindet, Erfolg meldet und dann Verkehr auf den falschen Weg schickt, hat meist ein Skriptproblem und kein Tunnelproblem, und eine Neuinstallation der Formel behebt es nur, weil das Skript ebenfalls neu installiert wird. Prüfen Sie die aktuelle Unterstützung der Formel für macOS und CPU-Architektur, bevor Sie darauf planen; ein Mac, der eine Shell bestens ausführt, hat womöglich trotzdem kein aktuelles Paket dafür.

Was der Quellweg wirklich tut

Ein Release-Archiv kommt mit einem erzeugten Buildsystem, daher existiert das vertraute ./configure von Anfang an. Ein git-Checkout nicht, weil die erzeugten Dateien Buildprodukte sind und keine Dinge, die das Projekt aufbewahrt. Genau deshalb taucht ./autogen.sh in den Anleitungen für Checkouts und nicht für Release-Archive auf.

./autogen.sh
./configure
make
make install

Jede Zeile tut etwas Bestimmtes, und zu wissen, welche fehlschlug, spart viel Raten. Der autogen-Schritt führt die autotools aus, um configure zu erzeugen. Der configure-Schritt prüft Compiler, Bibliotheken und Header, die der Client braucht, und schreibt dann die Makefiles, die das Gefundene widerspiegeln. Der make-Schritt kompiliert. Der install-Schritt kopiert die Ergebnisse irgendwohin in Ihren Pfad.

Genau bei dieser letzten Zeile geht Rat oft schief. Installation ist kein Beweis, dass der Build funktioniert hat, und ihn in einem beliebigen Downloadordner mit erhöhten Rechten auszuführen ist ein guter Weg, Dateien zu verstreuen, an die Sie sich später nicht erinnern. Scheitert configure an einer fehlenden Bibliothek, ist die nützliche Ausgabe der erste ausgegebene Fehler, nicht die letzten zwanzig Zeilen des Protokolls.

Sitzung und Netzwerkkonfiguration sind getrennt

Diese Unterscheidung entscheidet, ob eine Verbindung tatsächlich Verkehr trägt. Das Aufbauen der TLS-Sitzung verschafft eine Schnittstelle auf der Clientseite. Routen, Adressen und DNS-Resolver anzuwenden ist ein zweiter Schritt über das Netzwerkskript, und ein Build, der eine Binärdatei ohne das Skript erzeugt hat, hat einen halben Client.

Dieselbe Trennung erklärt, warum zwei Maschinen mit identischen Clients sich unterschiedlich verhalten: Das Skript konsultiert die Netzwerkkonfiguration des Systems, und diese Konfiguration umfasst alles andere, was eine Route beansprucht hat. Wenn ein geteilter Tunnel Verkehr an eine unerwartete Stelle schickt, tut der Tunnel seine Arbeit, und die Routingentscheidung ist das, was zu untersuchen ist.

Fragen Sie beim Debuggen also, welche Schicht versagt hat. Eine Sitzung, die nie zustande kommt, ist Protokoll, Zertifikat oder Zugangsdaten. Eine Sitzung, die zustande kommt und nichts weiterleitet, ist die Schnittstelle und das Skript. Ein installierter Client, der aus einem Netz funktioniert und aus einem anderen nicht, ist Erreichbarkeit, und daran ändert kein Neuaufbau etwas.

Wissen Sie, welche Binärdatei Sie ausführen

Ein von Hand installierter Build und eine paketierte Binärdatei können friedlich koexistieren, und welche läuft, hängt von Ihrem Pfad ab und nicht von Ihren Absichten. Finden Sie es heraus, bevor Sie jemandem eine Versionsnummer melden.

which -a openconnect
openconnect --version
brew list --versions openconnect

Der erste Befehl listet jede Kopie, die Ihre Shell sieht, in der Reihenfolge, in der sie sie versuchen würde. Der zweite sagt Ihnen, welche geantwortet hat. Wenn das nicht zu Ihrer Erwartung passt, führen Sie einen Build aus einem alten Experiment aus, und keine Konfigurationsänderung wird ihn verschieben.

Einen Client zu installieren ist keine Gateway-Freigabe

Eine funktionierende Binärdatei macht eine Bereitstellung nicht kompatibel. Bestätigen Sie Protokoll des Gateways, dessen Authentifizierungsablauf und etwaige Anforderungen an verwaltete Geräte mit den Leuten, denen es gehört, denn das sind Politik- und Anwendungsschichtfakten, die ein Build nicht liefern kann.

Die Build-Anleitung des Projekts behandelt die autotools-Reihenfolge und die Anforderung des Netzwerkskripts ausführlicher, und sie ist die Referenz, der man folgen sollte, nicht ein Blogbeitrag, der älter als Ihre macOS-Version ist. Wenn das Ziel nur das Verbinden ist, nehmen Sie das Paket, behalten Sie das Skript und lassen Sie den Compiler draußen.