OpenConnect vpnc-script: Welche Datei wird ausgeführt?
Der Helfer, der Routen und DNS einrichtet, ist vom Tunnel-Client getrennt. Finden Sie den Pfad, den der laufende Client verwendet, bevor Sie ihn durch eine Kopie aus einem Forum ersetzen.
OpenConnect kann den Tunnel-Handshake abschließen und Sie trotzdem ohne Route zum privaten Subnetz lassen, weil der Client und der Helfer, der den lokalen Netzwerkzustand ändert, zwei verschiedene Programme sind. Die Authentifizierung beweist, dass das Gateway die Sitzung akzeptiert hat; sie beweist nichts darüber, welche Schnittstelle, welche Routen oder welche Resolver-Einstellungen danach installiert wurden. Die meisten verwirrenden Berichte entstehen, weil der Helfer durch eine Kopie aus einer alten Antwort ersetzt wird, was das Verhalten für jede Verbindung auf dem Rechner ändert. Ermitteln Sie den Helfer, den der laufende Client tatsächlich aufruft, bevor Sie irgendetwas daran ändern.
Zwei Programme, zwei Zuständigkeiten
Der Client besitzt Transport, Authentifizierung und das Tunnelgerät. Ein separater Helfer besitzt das, was im lokalen System geschieht, sobald der Tunnel besteht: Adressierung auf der Schnittstelle, Routen für die vom Gateway angekündigten Subnetze und die Resolver-Konfiguration. Die Dokumentation zum OpenConnect-Helfer beschreibt diese Trennung und die Umgebung, die der Helfer erhält. Der Unterschied zählt im Fehlerfall, denn ein abgelehntes Passwort und eine fehlende Route sind nicht derselbe Vorfall, selbst wenn der Desktop für beides einen Dialog zeigt.
Diese Trennung im Kopf zu behalten erklärt auch, warum eine Verbindung Erfolg melden kann, während private Namen weiterhin nicht aufgelöst werden. Der Tunnel steht in beiden Fällen, und nur die lokale Integrationsstufe unterscheidet sich.
Ermitteln Sie den Helfer, den der laufende Client nutzt
Der Pfad wird beim Bau des Pakets festgelegt und kann bei jedem Aufruf überschrieben werden, daher hat die Datei, die Sie aus einer anderen Distribution kennen, möglicherweise nichts mit dieser Verbindung zu tun. Fragen Sie den laufenden Prozess statt der Dokumentation, die Sie zufällig geöffnet haben.
openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null
Wenn die Prozesszeile ein --script Argument trägt, gewinnt diese Datei gegen den einkompilierten Standard. Ältere Pfade wie /etc/vpnc/vpnc-script können existieren und trotzdem ungenutzt bleiben, weshalb ihr Löschen oder Bearbeiten bei einem neueren Build nichts ändert. Prüfen Sie auch das Änderungsdatum, denn ein Helfer, den jahrelang niemand angefasst hat, ist ein starkes Zeichen dafür, dass der mitgelieferte Standard die Arbeit erledigt.
Die NetworkManager-Integration ist ein dritter Eigentümer, mit eigenem Helfer und eigenen Profileinstellungen. Ein zweites Routen- oder Resolver-Skript über diese Integration zu legen, verdoppelt Routen und hinterlässt einen Resolver, den zwei Programme beide zu verwalten behaupten. Wählen Sie einen Eigentümer pro Verbindung und deaktivieren Sie den anderen vor dem Test.
Lesen Sie die erste fehlgeschlagene Operation, nicht die letzte Warnung
Schnittstellenkonfiguration, Routeninstallation, Resolver-Auswahl und das Aufräumen veralteten Zustands sind getrennte Schritte, und die zuletzt ausgegebene Warnung ist oft eine Aufräumbeschwerde und nicht der Fehler, der die Verbindung brach. Lesen Sie nach oben bis zur ersten konkreten Operation, die fehlgeschlagen ist. Ein Helferfehler, der eine Datei oder eine Adresse nennt, ist mehr wert als zehn Zeilen Abbaurauschen.
Vergleichen Sie das beabsichtigte lokale Ergebnis mit dem beobachteten: Das Tunnelgerät existiert, eine Route zu einer bekannten privaten Adresse führt hindurch, und der Resolver antwortet für einen privaten Namen. Ein Helfer, der bei den ersten beiden erfolgreich ist und beim dritten scheitert, deutet auf die Resolver-Richtlinie und nicht auf das Routing. Ein Helfer, der das Gerät gar nicht konfiguriert, wurde wahrscheinlich nie ausgeführt, und das ist eine Frage der Berechtigungen und nicht des Netzwerks. Bestätigen Sie das Ausführungsbit und das Dienstkonto, bevor Sie irgendeine Logik umschreiben.
Prüfen Sie Verbinden, Wiederverbinden und Trennen
Die Einrichtung ist nur die Hälfte des Vertrags, denn derselbe Helfer muss den Zustand, den er besitzt, wiederherstellen oder entfernen, wenn der Tunnel schließt. Ein Helfer, der Routen hinzufügt und nie entfernt, hinterlässt dem Rechner einen veralteten Pfad, der die Sitzung überlebt.
ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'
Führen Sie die ersten drei aus, während Sie verbunden sind, trennen Sie die Verbindung, und führen Sie sie dann erneut aus und bestätigen Sie, dass Route und Resolver-Eintrag verschwunden sind. Die vierte Zeile zeigt, ob der Helfer überhaupt aufgerufen wurde und welchen ausführbaren Pfad der Dienst verwendet hat. Halten Sie dieses Ausgabepaar im Ticket fest, denn genau das Vorher-Nachher macht einen Aufräumfehler offensichtlich.
Halten Sie den Helfer gepackt und für das Dienstkonto ausführbar, denn ein Skript, das in Ihrer Shell läuft, kann unter einer eingeschränkten Dienstrichtlinie trotzdem verweigert werden. Wenn eine Anpassung wirklich nötig ist, dokumentieren Sie Zweck und Eigentümer und vergleichen Sie sie bei jedem Upgrade mit der gepackten Version. Ein unerklärter Fork eines Helfers ist eines der wenigen Dinge, die eine funktionierende Verbindung ein Jahr später scheitern lassen können.