So stellst du ein OpenVPN-Clientprofil aus ausgegebenen Dateien zusammen

Eine ovpn-Datei ist Konfiguration, kein Zertifikat. Baue ein Clientprofil aus der ausgegebenen CA, dem Zertifikat und dem Schlüssel und lege dann Identität und Verzeichnis fest.

Dein Betreiber übergibt dir ein CA-Bundle, ein Clientzertifikat und dessen Schlüssel, und der Client startet erst, wenn diese in einem Profil verbunden sind. Das Profil ist Konfiguration: Es verweist auf diese Dateien, enthält sie nicht, und durch Bearbeiten wird daraus kein Zertifikat. Die Anleitung beginnt bei einem bereits freigegebenen Laptop und endet mit einem Profil, das du aus einem bekannten Verzeichnis starten kannst. Sie erzeugt keine CA, registriert kein neues Zertifikat und fasst den Server nicht an.

Ziel ist hier ein Linux-OpenVPN-2.6-Kommandozeilenclient, geroutet über TUN via UDP, mit Zertifikatsauthentifizierung.

Sammle nur die Dateien auf Clientseite

Arbeite in einem geschützten Verzeichnis und sammle das freigegebene CA-Vertrauensmaterial, dein ausgegebenes Clientzertifikat und den passenden privaten Schlüssel ein. In diesem Beispiel heißen sie ca.crt, laptop-a.crt und laptop-a.key. Die Dateinamen sind nur Etiketten; sie sagen nichts darüber aus, was die jeweilige Datei enthält.

Wenn du den Schlüssel bei der Registrierung erzeugt hast, hat er die Maschine nie verlassen; vom Aussteller müssen nur das signierte Zertifikat und die öffentliche Kette zurückkommen. Prüfe, ob das Zertifikat die Clientrolle trägt, die der Dienst erwartet. Prüfe auch, ob der Schlüssel zu diesem Zertifikat gehört und nicht zu einem früheren aus einem vorherigen Versuch. Ein nicht zusammenpassendes Paar erzeugt viel später einen TLS-Fehler, der wie ein Serverproblem aussieht.

Lass den privaten Signaturschlüssel der CA, den privaten Schlüssel des Servers und die DH-Parameter aus diesem Paket heraus.

Verbinde die Dateien in einem kleinen Profil

Das folgende Profil ist bewusst kurz. Jede Zeile wählt entweder den Endpunkt, schränkt die Identität ein, die der Client akzeptiert, oder verweist auf eine der drei Dateien.

client
dev tun
proto udp
remote vpn.example.net 1194
nobind

remote-cert-tls server
verify-x509-name vpn-gateway name
ca ca.crt
cert laptop-a.crt
key laptop-a.key

Die Zeile remote wählt den Netzwerkendpunkt. remote-cert-tls server besteht darauf, dass die Gegenseite ein Zertifikat mit Serverrolle vorlegt. verify-x509-name fixiert den erwarteten Namen, hier vpn-gateway als Common Name des Serverzertifikats mit OpenVPNs Standard-Namensfeld. Dieser Wert wird nicht aus dem DNS-Hostnamen abgeleitet, also nutze das Identitätsschema, das der Betreiber vorgegeben hat.

Lass diese Prüfungen nicht fallen, nur weil ein Testendpunkt ein anderes Zertifikat zeigt.

Dieses Basisprofil setzt keine separate Kontoabfrage und keinen Schlüssel für den Steuerkanal voraus. Wenn der Dienst auth-user-pass, tls-auth oder tls-crypt benötigt, behalte die Konfiguration und das Material, das du bekommen hast, denn ein selbst erzeugtes Geheimnis für den Steuerkanal passt nicht zu dem des Servers. Behalte auch die Verschlüsselungsrichtlinie des Dienstes, statt Kompressions- oder Verschlüsselungszeilen aus einem alten Beispiel zu übernehmen.

Mach das Arbeitsverzeichnis explizit

Relative Pfade folgen dem Arbeitsverzeichnis des Prozesses, nicht dem Ort der .ovpn-Datei.

Das überrascht Leute, die das Profil in einen neuen Ordner verschieben und erwarten, dass der Schlüssel mitwandert. Für ein vom Administrator gewähltes Verzeichnis wechselt der Befehl unten in einen absoluten Pfad, bevor er das Profil und seine Verweise liest.

sudo openvpn --cd /etc/openvpn/client/laptop-a --config laptop-a.ovpn

Ein Importassistent auf dem Desktop oder ein Systemdienst kann die Abhängigkeiten für dich bündeln und eigene Regeln anwenden. Er kann auch ein anderes Arbeitsverzeichnis verwenden als das, in dem du getestet hast. Prüfe, wie deine Startmethode die Pfade zu Schlüssel, Zertifikat und CA auflöst. Nur die .ovpn-Datei zu verschieben verschiebt nicht den separaten privaten Schlüssel.

Halte den Schlüssel nur für den vorgesehenen Benutzer oder die Dienstidentität lesbar.

Prüfe die Übergabe, nicht die Dateinamen

Prüfe vor der ersten autorisierten Verbindung den Endpunkt, die Zertifikatsidentität, den Aussteller und das Gültigkeitsfenster. Bestätige dann, dass die Dateiverweise aus dem Arbeitsverzeichnis aufgelöst werden, das du tatsächlich verwenden wirst. Teste nach dem Verbinden das Anwendungs- und DNS-Verhalten, das die Routingrichtlinie liefern soll. Drei lesbare Dateien beweisen nichts über die Serverautorisierung oder über einen nutzbaren Ressourcenpfad.

Erscheint eine Passphrasenabfrage, gehört sie zum privaten Schlüssel, nicht zu einem VPN-Konto.

Zum Schluss inventarisiere das Paket als Anmeldedatenmaterial. Dasselbe Zertifikat und denselben Schlüssel an einen zweiten Laptop zu geben, kopiert die Identität, und das Umbenennen der Datei verschafft dir keine zweite Registrierung. Das ist der Unterschied zwischen dem Zusammenstellen eines Profils und dessen Ausgabe.

Ähnliche Artikel