OpenVPN : eine .ovpn-Datei unter Linux starten und einen Fehler verstehen

Sie haben eine .ovpn-Datei erhalten, Sie starten OpenVPN auf einer Debian- oder Ubuntu-VM, dann zeigt das Terminal einen Fehler an oder bleibt vor der Verbindung hängen. Die Datei kann gültig sein, während sie auf ein fehlendes Zertifikat, einen gefilterten Port oder eine Route zeigt, die Ihre SSH-Sitzung unterbricht. Überprüfen Sie das Profil, notieren Sie den ersten Fehler, und überprüfen Sie dann die Route und den internen Dienst nach der Verbindung.

Die .ovpn-Datei lesen, bevor Sie OpenVPN starten

Halten Sie eine lokale Konsole, eine Anbieter-Konsole, iDRAC/IPMI oder ein bereits genehmigtes Management-Netzwerk bereit. Führen Sie den Test von diesem unabhängigen Zugang aus. redirect-gateway kann in der Datei geschrieben oder vom Server nach der Verbindung übertragen werden. Die Standardroute kann dann durch das Tunnel geleitet werden. Eine zweite SSH-Sitzung, die die gleiche Route verwendet, ist kein Backup-Zugang.

Wenn Sie vor dem Test eine SSH-Verbindung haben, zeigen Sie die Client-Adresse an und notieren Sie sie. Setzen Sie diese Adresse in der Kontrollkonsole, die nach der Verbindung verwendet wird, zurück, bevor Sie ihre Route überprüfen. Eine Wiederherstellungskonsole ermöglicht den Zugriff auf den Server, garantiert jedoch nicht, dass Ihre SSH-Sitzung offen bleibt.

# In der SSH-Sitzung vor dem Start:
printf '%sn' "$SSH_CLIENT"
# In der Kontrollkonsole nach der Verbindung:
SSH_CLIENT_IP='198.51.100.42' # ersetzen Sie dies durch die notierte Client-Adresse
ip route get "$SSH_CLIENT_IP"

Platzieren Sie die Datei in einem Verzeichnis, das nur für Ihr Konto reserviert ist, und beschränken Sie deren Berechtigungen, wenn Schlüssel integriert sind. Geben Sie keine Identifikationsdaten oder Passwörter in der Testdatei oder in einem Git-Repository an.

mkdir -p ~/vpn-test
install -m 600 /chemin/recu/client.ovpn ~/vpn-test/client.ovpn
cd ~/vpn-test
grep -nE '^[[:space:]]*(remote|proto|port|ca|cert|key|pkcs12|tls-auth|tls-crypt|tls-verify|auth-user-pass|auth-user-pass-verify|redirect-gateway|redirect-private|route|route-ipv6|route-gateway|route-table|route-noexec|route-nopull|pull-filter|config|plugin|script-security|up|down|route-up|route-pre-down|ipchange|dns-updown|management|daemon|log|log-append|syslog|status|writepid|askpass|cd|chroot|user|group|learn-address|client-connect|client-disconnect)' client.ovpn

Diese Lesung zeigt den entfernten Host, das Protokoll, die Zertifikatdateien und den Authentifizierungsmodus an, ohne deren Inhalt anzuzeigen. Wenn config eine andere Datei lädt, lesen Sie sie erneut aus dem Profilverzeichnis, filtern Sie erneut und verfolgen Sie jede config bis zur letzten Datei. Die gesamte Kette muss verstanden werden, bevor ein Start erfolgt. up, down, route-up, route-pre-down, ipchange und tls-verify starten externe Befehle. plugin lädt eine Bibliothek in den OpenVPN-Prozess. management öffnet eine Kontrollschnittstelle, die nicht exponiert werden sollte. Ein Client-Profil, das learn-address, client-connect, client-disconnect oder auth-user-pass-verify enthält, wird für diese Diagnose abgelehnt. Halten Sie auch an, wenn einer der anderen Pfade unbekannt ist. Externe Skripte erfordern einen Wert für script-security von 2 oder 3, einen Wert, den das Profil selbst festlegen kann. Überprüfen Sie auch auth-user-pass: ohne Argumente fordert OpenVPN die Anmeldedaten an der Eingabeaufforderung an; mit einem Pfad liest es diese Datei und überträgt deren Inhalt an den Server des Profils. Der Start mit sudo ist normal, um die Schnittstelle und die Routen zu erstellen, aber keine referenzierte Datei darf unbekannt sein.

# Für jeden Pfad, der nach "config" gefunden wird, aus ~/vpn-test:
sed -n '1,220p' chemin-inclus.conf

Eine Datei, deren Herkunft oder Direktiven unbekannt bleiben, darf niemals auf einem Produktionsserver oder auf einer Maschine, deren SSH-Zugang kritisch ist, gestartet werden. Der erste Versuch erfolgt in einer wegwerfbaren VM mit einer unabhängigen Konsole. Diese Lesung reduziert das Risiko, sie verwandelt jedoch ein beliebiges Profil nicht in ein sicheres Profil. Weisen Sie auch daemon, log, log-append und syslog für diese Diagnose zurück: Sie verschieben die Nachrichten aus dem Terminal und können den Prozess im Hintergrund belassen.

Wenn das Profil relative Pfade referenziert, bewegen Sie nicht nur client.ovpn. Bewahren Sie das empfangene Verzeichnis an einem kontrollierten Ort auf oder kopieren Sie jede Abhängigkeit, die Sie erneut überprüft haben, mit der gleichen Verzeichnisstruktur und eingeschränkten Rechten. Zum Beispiel muss ein Profil, das ca ca.crt angibt, ca.crt in ~/vpn-test finden.

install -m 600 /chemin/recu/ca.crt ~/vpn-test/ca.crt

Eine fehlende oder nicht lesbare Abhängigkeit ist ein Fehlschlag des Profils, unterscheidbar von einem TLS-Fehler nach dem Netzwerkversuch. Eine .ovpn-Datei kann auch die Zertifikate zwischen Tags einbetten, diese Kontrolle zeigt dann keinen externen Pfad an.

find ~/vpn-test -maxdepth 1 -type f -printf '%f %mn'
# Für proto udp4/tcp4 :
getent ahostsv4 vpn.exemple.net
# Für proto udp6/tcp6 :
getent ahostsv6 vpn.exemple.net
ip -brief link show > ~/vpn-test/links-before.txt

Ersetzen Sie den Host und die Familie durch die Werte von remote und proto. Ein Profil kann mehrere Zeilen remote enthalten. Wenn die Familie offen bleibt, überprüfen Sie beide Ausgaben und bewahren Sie die Adresse auf, die tatsächlich von OpenVPN im Protokoll angezeigt wird. Die OpenVPN-Verbindung selbst bleibt der nützliche Test des Protokolls und des Ports, egal ob es sich um UDP oder TCP handelt.

Den Client im Vordergrund starten und das Protokoll behalten

Starten Sie den Client im Vordergrund. Das Terminal sollte dann die kontaktierten Adressen und den ersten verwertbaren Fehler anzeigen. Installieren Sie das Paket, wenn openvpn fehlt:

command -v openvpn || { sudo apt update && sudo apt install openvpn; }
sudo openvpn --config ~/vpn-test/client.ovpn --verb 3

Mit --verb 3 behalten Sie den ersten klaren Fehler, die Adresse des Servers und die Phase, in der der Client stoppt.

• Options error oder eine nicht gefundene Datei weisen auf einen Pfad, eine Direktive oder ein Zertifikat hin, das vor einem weiteren Versuch korrigiert werden muss.
• TLS Error nach dem Verbindungsversuch verlangt eine Überprüfung des Servers, des Ports, des UDP/TCP-Protokolls, der Netzwerkfilterung, von tls-auth oder tls-crypt, von Zertifikaten, von der Systemzeit und von den kryptografischen Einstellungen des Profils.
• Eine Aufforderung zur Eingabe von Anmeldedaten kann von auth-user-pass kommen. Geben Sie es an der Eingabeaufforderung ein oder verwenden Sie den vorgesehenen Mechanismus Ihres Anbieters, ohne das Geheimnis zu client.ovpn hinzuzufügen.
• Die Nachricht Initialization Sequence Completed bestätigt, dass der Client seine Initialisierung abgeschlossen hat. Es beweist jedoch noch nicht, dass die interne Ressource, die erwartet wird, erreichbar ist.

Halten Sie den Befehl während der nächsten Prüfung geöffnet. Stoppen Sie ihn mit Ctrl+C erst, nachdem Sie die Schnittstelle, die Routen und den internen Dienst überprüft haben.

Die Schnittstelle und die Route nach der Verbindung überprüfen

Speichern Sie die Schnittstellen vor der Verbindung und vergleichen Sie sie danach. tun transportiert IP-Pakete, tap emuliert eine Ethernet-Schnittstelle. Die Direktive dev kann ebenfalls einen Namen vorschreiben. Verwenden Sie nur den tatsächlich erstellten Namen. ip route get zeigt das Gerät an, das Linux auswählen würde, ohne ein Paket zu senden.

# Nach „Initialization Sequence Completed“:
ip -brief link show | diff -u ~/vpn-test/links-before.txt -
VPN_IF='name-der-erstellten-schnittstelle'
ip -brief address show dev "$VPN_IF"
ip route get 10.8.0.10
ip route get 1.1.1.1
ip route get "$SSH_CLIENT_IP"

Ersetzen Sie 10.8.0.10 durch ein internes Ziel, das vom Team, das das VPN bereitstellt, dokumentiert wurde. Seine Route sollte die Schnittstelle des Tunnels erwähnen, wenn dieses Netzwerk durch OpenVPN geführt wird. Überprüfen Sie auch die Route zu SSH_CLIENT_IP, falls Sie vor dem Test eine entfernte Sitzung hatten.

Die Route beweist nicht, dass der interne Dienst antwortet. Testen Sie dann den erwarteten Dienst mit der Adresse und dem Port, die Ihr Team dokumentiert hat. Für einen HTTPS-Dienst, der eine Gesundheitsseite anzeigt, zum Beispiel :

getent hosts intranet.exemple.lan
curl --fail --silent --show-error --connect-timeout 5 --max-time 10 --output /dev/null --write-out '%{http_code}n' https://intranet.exemple.lan:443/health

Ersetzen Sie diesen Namen, den Port und den Pfad durch die des tatsächlichen Dienstes. Der erste Befehl sollte eine interne Adresse zurückgeben. Der zweite sollte den vom Dienst erwarteten Code anzeigen, wie 200 oder 204. curl überprüft auch das TLS-Zertifikat: Installieren Sie die interne CA oder verwenden Sie die Dokumentation des Dienstes, falls erforderlich, ohne --insecure hinzuzufügen. Für einen internen DNS-Abgleich bevorzugen Sie es, einen Namen und einen Resolver zu befragen, die Ihr Team dokumentiert hat.

Ich würde diesen einmaligen Start vor einem openvpn-client@... Dienst auf einem Server wählen, da das Diagnostic getrennt vom Start bleibt. Überprüfen Sie nach Ctrl+C, dass die Schnittstelle verschwunden ist, dass die Route zum internen Ziel nicht mehr das Tunnel verwendet und dass die Route zur notierten SSH-Adresse auf das erwartete Gerät zurückkehrt. Ein Profil mit down oder route-pre-down Skripten erfordert diese Kontrolle, es ermöglicht nicht zu vermuten, dass die Bereinigung erfolgreich war.

ip link show "$VPN_IF"
ip route get 10.8.0.10
ip route get "$SSH_CLIENT_IP"

Der erste Befehl sollte anzeigen, dass die Schnittstelle nicht mehr existiert. Vergleichen Sie die beiden Routen mit ihren vorherigen Ausgaben. Eine Route, die noch mit der entfernten Schnittstelle verbunden ist, oder ein Fehler im Bereinigungsskript erfordert eine Überprüfung vor einem neuen Versuch.