Zwei OpenVPN-Profile vergleichen, ohne Schlüssel preiszugeben

Zwei Profile, das eine verbindet sich und das andere nicht, und der schnelle Weg, den Grund zu sehen, ist ein Diff. Das Problem: Derselbe Diff druckt den eingebetteten privaten Schlüssel, den statischen Schlüssel und jeden Credential-Block, den die Datei enthält, und die Leute fügen die Ausgabe in einen Chat ein, bevor sie es bemerken. Die Entscheidung, was Sie vergleichen, steht vor dem Ausführen des Befehls. Vergleichen Sie Struktur und Rollen auf geschützten Kopien, und bauen Sie eine separate geschwärzte Datei, wenn jemand anderes sie sehen muss.

Was eine .ovpn-Datei tatsächlich enthält

Eine .ovpn-Datei ist eine Konfiguration mit optionalen eingebetteten Blobs. Sie kann ein CA-Zertifikat, ein Client-Zertifikat, einen privaten Schlüssel, einen tls-auth oder tls-crypt-Schlüssel sowie Direktiven enthalten, die auf externe Dateien zeigen oder Credentials abfragen. Zwei Dateien können fast identisch aussehen und sich nur innerhalb eines Blobs unterscheiden, oder in einer Direktive, die den Transport vollständig ändert. Die Zeilenzahl sagt Ihnen nichts darüber, was davon passiert ist.

Ein Unterschied innerhalb eines Schlüsselblocks ist kein öffentlicher Beweis für irgendetwas. Ein neu ausgestelltes Zertifikat und ein neu verschlüsseltes können dieselbe Form der Änderung erzeugen, die Blob-Abweichung sagt also, dass das Material anders ist, nicht welche Entscheidung es erzeugt hat. Behandeln Sie sie als Signal, Felder zu vergleichen, nicht als Befund.

Nach Rolle vergleichen, nicht nach Zeile

Folgen Sie der eigenen Reihenfolge der Verbindung: zuerst Endpunkt und Transport, dann Vertrauen und erwartete Identität, dann Benutzerauthentifizierung, dann Routen, DNS und Skript-Hooks. Diese Reihenfolge entspricht dem, was der Client tut, also ist der erste Unterschied, auf den Sie treffen, das erste, was die Verbindung hätte brechen können. Alphabetisches Vergleichen verteilt verwandte Einstellungen stattdessen über die gesamte Ausgabe.

Ein feldbewusster Durchlauf betrachtet diese Punkte in dieser Reihenfolge. Alles, was der Client interaktiv abfragt, gehört in die Authentifizierungszeile und nicht in die Vertrauenszeilen.

• remote, proto und Port, einschließlich jedes Verbindungsblocks.
• ca und cert: Aussteller, Betreff und Ablaufdatum.
• Ob überhaupt ein privater Schlüssel vorhanden ist, niemals was er enthält.
• tls-auth oder tls-crypt-Präsenz und Schlüsselrichtung.
• Authentifizierungsdirektiven, einschließlich jeder Referenz auf eine Credential-Datei.
• Routen, DNS-Optionen und Skript-Hooks, die beim Verbinden laufen.

Wenn eine Datei mehrere Verbindungsblöcke enthält, halten Sie jede Option bei ihrem Endpunkt. Nur die erste remote-Zeile zu vergleichen kann die Alternative übersehen, die der Client in diesem Netz tatsächlich wählt.

Warum ein einfacher Diff das falsche Werkzeug ist

Ein einfacher Diff ist für Text gebaut, nicht für Geheimnisse. Er druckt einen privaten Schlüssel fröhlich in den Scrollback und sagt Ihnen nicht, dass die Direktive, die Sie anstarren, für den Fehler irrelevant ist. Feldextrakte sind zugleich sicherer und lesbarer, weil Zertifikatsmaterial als Metadaten statt als Bytes verglichen werden kann.

openssl x509 -in ca.crt -noout -subject -issuer -enddate
openssl x509 -in client.crt -noout -subject -issuer -enddate
grep -E '^(remote|proto|port|tls-auth|tls-crypt|route|dhcp-option)' profile.ovpn

Die ersten beiden Befehle drucken Identität und Gültigkeit, ohne den Schlüssel anzufassen, ihre Ausgabe ist also sicher zum Einfügen. Das grep druckt Direktivnamen und Werte, aber nie die Blob-Inhalte, was es zum richtigen ersten Durchlauf macht, wenn Sie einen Transport- oder Routingunterschied vermuten. Muss ein Blob selbst verglichen werden, vergleichen Sie seinen Hash statt des Inhalts.

Eine geschwärzte Kopie für das Ticket bauen

Entfernen Sie echte Geheimnisse und unnötige Identifikatoren, behalten Sie aber Feldnamen und genug Struktur, um den Unterschied zu erklären. Ein Marker gleicher Form verrät immer noch, wo das Material sitzt und wie lang es war, entscheiden Sie also, ob auch das akzeptabel ist. Prüfen Sie den endgültigen Anhang selbst, statt dem Befehl zu vertrauen, von dem Sie glauben, ihn ausgeführt zu haben. Bearbeiten Sie nicht das Arbeitsoriginal, nur um ein Beispiel zu erzeugen, denn ein geschwärztes Profil ist nicht unbedingt ausführbar und sollte niemals erneut importiert werden.

Halten Sie die Originale anhand von Dateiname und Hash identifizierbar, statt sie in drei Verzeichnisse mit ähnlichen Namen zu kopieren. Ein Hash-String genügt, um zu beweisen, welche Datei geprüft wurde, und kostet nichts, wenn er leckt. Beschneiden Sie die Kopien, nachdem die Änderung geschlossen ist, damit die nächste Person eine maßgebliche Datei erbt.

Den Vergleich an einen Fehler binden

Ein Vergleich verdient seine Kosten, wenn er eine Frage zu einem Import oder einem Verbindungsfehler beantwortet. Benennen Sie zuerst den fehlschlagenden Schritt und vergleichen Sie dann nur die Felder, von denen dieser Schritt abhängt; alle Credentials des Clients in einem Verzeichnis zu sammeln macht das nächste Leck wahrscheinlicher und die nächste Diagnose langsamer. Je enger die Frage, desto kürzer die Liste der Felder, die sie beantworten können.

Wenn eine neue Datei vom Betreiber kam, bestätigen Sie ihren Verteilungspfad, bevor Sie Vertrauensmaterial ersetzen. Prüfen Sie nach der Änderung die importierte Kopie, die der Client tatsächlich gewählt hat, und das ausgehandelte Ergebnis, denn eine Direktive kann von einer anderen Client-Version ignoriert oder anders gelesen werden. Die Datei auf der Platte ist kein Beweis für die Verbindung, die lief. Die Direktiv-Semantik steht im OpenVPN-2.6-Handbuch.