openvpn3 session-start ignoriert Ihre Datei mit Anmeldedaten

Verbinden Sie sich mit dem 2.x-Client, und das Profil funktioniert; geben Sie dieselbe Datei an den 3.x-Client, und er bleibt an einer Passwortabfrage stehen. Übergeben Sie --auth-user-pass creds.txt an openvpn3 session-start, und das Ergebnis ist dasselbe, weil der neuere Client keine Stufe hat, die die Datei liest. Die Ablehnung ist beabsichtigt: Anmeldedaten gehören zu einer Sitzung, und eine Sitzung wird von einem Dienst erstellt, nicht vom Prozess in Ihrem Terminal. Wählen Sie zwischen der interaktiven Abfrage und dem Autoload-Helfer und wissen Sie, was jeder von beiden speichert.

Warum die gespeicherte Datei nirgendwohin kann

Im neueren Entwurf sind Konfigurationsverwaltung und Sitzungsverwaltung getrennte Dienste, die über den Systembus sprechen. Genau diese Trennung erlaubt es einem gewöhnlichen Benutzer, eine Sitzung zu starten, ohne dass ein privilegierter Daemon in seinem Namen eine geschützte Passwortdatei liest. Dateibasierte Anmeldedaten haben in diesem Modell keinen Platz, weil es keinen Start auf der Daemon-Seite gibt, der sie lesen würde. Die Ablehnung ist eine Folge der Architektur, kein fehlendes Merkmal.

Das alte Muster verdient einen Namen, damit man es leichter verlernen kann: Ein Profil verweist auf eine Datei mit Anmeldedaten, und der Daemon liest sie, wenn der Tunnel startet. Im neuen Modell gehören Anmeldedaten zu einer Sitzung und werden bereitgestellt, wenn diese Sitzung beginnt. openvpn3 session-start --config work.ovpn fragt danach, und --auth-user-pass creds.txt wird abgelehnt, weil nichts auf diesem Weg die Datei öffnen würde. Jedes 2.x-Rezept, das Sie finden, setzt eine Stufe voraus, die es nicht mehr gibt.

Konfiguration und ortsspezifische Einstellungen sind ebenfalls getrennt, was eine zweite Überraschung erklärt. Ein Profil kann vollständig aussehen, während der erzeugten Verbindung Routing- und Resolver-Konfiguration fehlt. Diese Teile werden als ortsspezifische Einstellungen angewendet, getrennt von der importierten Datei.

Der Weg über die Abfrage und die Sitzung, die er hinterlässt

Das Passwort beim Sitzungsstart bereitzustellen ist der vorgesehene Arbeitsablauf. Der Client fragt einmal, übergibt die Anmeldedaten an das Sitzungs-Backend und fährt fort:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

Auf diesem Weg wird nichts auf die Festplatte geschrieben. Die Sitzung läuft auch weiter, nachdem das Terminal geschlossen wurde, was Leute überrascht, die erwarten, dass der Prozess mit ihrer Shell stirbt. Genau das ist der Sinn davon, die Sitzungsverwaltung in einen Dienst zu verlagern. Die Sitzung überlebt das Terminal, das sie angefordert hat, und muss ausdrücklich beendet werden.

Für eine Workstation mit einem Menschen davor ist dies auch die sicherste Option, weil es kein gespeichertes Geheimnis zu schützen oder zu vergessen gibt. Sie ist nur dort ungeeignet, wo niemand anwesend ist, um zu tippen.

Automatisierung ohne eine Person an der Tastatur

Wo sich eine Maschine ohne eine Person verbinden muss, liefert das Projekt openvpn3-autoload. Es liest ein Verzeichnis mit Profilen und einen passenden Deskriptor pro Profil, und der Deskriptor liefert die Anmeldedaten im Klartext. Der Helfer ist eine eigene Binärdatei, üblicherweise unter /usr/sbin/openvpn3-autoload, kein Schalter von session-start. Einrichten bedeutet, das Verzeichnis anzulegen, das Profil unter dem Namen zu kopieren, den der Deskriptor erwartet, und den Deskriptor zu schreiben.

Eine Einrichtung pro Benutzer sieht so aus und wird als das Konto ausgeführt, dem die Sitzung gehören wird. Der Verzeichnismodus hält andere lokale Benutzer draußen:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

Der Deskriptor benennt die Anmeldedaten und verlangt einen automatischen Start. Halten Sie den Passwortwert aus der Versionskontrolle heraus:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

Rufen Sie dann den Helfer einmal auf und bestätigen Sie, dass die Sitzung erscheint. Der zweite Befehl ist die Prüfung, kein weiterer Einrichtungsschritt:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

Beim Start verwendet eine gepackte Einheit namens openvpn3-autoload.service das systemweite Verzeichnis /etc/openvpn3/autoload, nicht das pro Benutzer. Dieser Ort braucht Root-Eigentum und einen strengeren Modus, und der Deskriptor enthält das Passwort weiterhin im Klartext. Der Kompromiss ist ausdrücklich: Das Passwort liegt jetzt auf der Festplatte, also behandeln Sie dieses Verzeichnis als Geheimnis, schließen Sie es aus Backups außerhalb des Hosts aus und wählen Sie den interaktiven Weg, wann immer eine Person anwesend ist.

Busfehler, die wie Passwortfehler aussehen

Manche Fehler, die den Anmeldedaten zugeschrieben werden, sind nichts dergleichen. Ein Berechtigungsfehler, der den Dienstaktivierungspfad nennt, bedeutet eines von zwei Dingen: Das Backend läuft nicht, oder der Aufrufer darf es nicht aktivieren. Keine Profilbearbeitung ändert eines davon. Prüfen Sie den Dienstzustand und die mitgelieferte Bus-Policy, bevor Sie die Konfiguration anfassen.

Die folgenden Befehle trennen die beiden. Der erste meldet, ob das Backend läuft; der zweite zeigt aktuelle Busfehler:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

Die andere häufige Fehldeutung ist eine Sitzung, die erscheint und sofort verschwindet. Dieses Muster bedeutet meist, dass die ortsspezifischen Einstellungen nie angewendet wurden, sodass der Tunnel ohne die Routing- und Resolver-Änderungen hochkam, die ihn nützlich machen. Lesen Sie den Ablauf statt der letzten Zeile: ob die Sitzung erstellt wurde, ob sie einen verbundenen Zustand erreichte und ob sie überlebte, sind drei getrennte Fakten.

Wenn der ältere Client noch verwendet wird

Der 2.x-Client akzeptiert noch eine Datei mit Anmeldedaten, und ein Schlüsselbund kann seine Abfrage beantworten, ohne dass das Geheimnis je auf die Festplatte gelangt. Ein Wrapper löst den Eintrag auf, sodass die Datei den Nachschlag benennt statt das Passwort. Diese Anordnung setzt einen entsperrten Schlüsselbund voraus, was ein Container ohne Anmeldesitzung oder eine Einheit, die startet, bevor sich jemand anmeldet, nicht bieten kann. Das Nachschlagewerkzeug meldet dann eine Sammlung, in die es nicht schreiben kann, sodass der Fehler wie ein Anmeldedatenfehler aussieht, obwohl es ein Schlüsselbundfehler ist.

Bevor Sie irgendetwas davon bauen, prüfen Sie, ob eine Keepalive-Einstellung im Profil die Notwendigkeit eines Neustarts ganz beseitigt. Eine Sitzung, die oben bleibt, erreicht nie die Abfrage, die Sie automatisieren wollen.