Sie brauchen den privaten Schlüssel nicht, um ein VPN zu debuggen

Die Anfrage klingt vernünftig: Senden Sie die Konfiguration, damit der Support sieht, was falsch ist. Genau so landen private Schlüssel in Ticketsystemen und Chat-Protokollen. Eine Konfiguration ist eine Identität, keine Diagnose, und wer Ihren Tunnel debuggt, braucht fast nie die Hälfte, die beweist, wer Sie sind. Die Statusausgabe beantwortet dieselben Fragen ohne dieses Risiko.

Der Mythos lautet, eine Konfiguration sei die einzige vollständige Sicht. Sie ist die am wenigsten sichere vollständige Sicht.

Der Mythos: Der Support braucht die Konfiguration

Der Support braucht den Fehlertext, die Client- und Serverversionen, den Endpunkt, den Handshake-Zustand und die Reihenfolge der Ereignisse. All das ist Status. Eine Konfiguration fügt Schlüssel hinzu, und Schlüssel sind das, was jemand anderem erlaubt, Sie zu sein. Eine Konfiguration herauszugeben, um ein Routingproblem zu beheben, ist wie den Pass per Post zu schicken, um einen verspäteten Flug zu erklären. Die Anfrage kommt meist von jemandem, der Ihr Netzwerk nie gesehen hat, und verlangt das, was am einfachsten anzuhängen ist.

Senden Sie die kleinste Ausgabe, die die Frage beantwortet, nicht die größte, die Sie finden können.

Was der Status tatsächlich zeigt

WireGuards wg show gibt Schnittstellen, Peers, erlaubte IP-Adressen, Endpunkte, den letzten Handshake und Übertragungszähler aus und gibt den privaten Schlüssel nicht aus. Die Status- und Logausgabe von OpenVPN liefert Verbindungszustand und Fehler ohne die eingebetteten Schlüsselblöcke. Beides reicht, um zu sehen, ob ein Handshake abgeschlossen wird, ob sich Zähler bewegen und welcher Peer verwendet wird, was das wg-Handbuch als Statusansicht dokumentiert.

Wenn ein Helfer nach der Konfiguration fragt, bevor er nach dieser Ausgabe fragt, fragen Sie, was die Konfiguration zeigen würde, was der Status nicht zeigt.

Wo sich Geheimnisse in jedem Format verstecken

WireGuard-Konfigurationsdateien enthalten PrivateKey-Zeilen, und öffentliche Peer-Schlüssel plus Endpunkt-Metadaten sind auch ohne sie noch identifizierend. OpenVPN-Profile können <key>- und <tls-crypt>-Blöcke einbetten oder auf separate Dateien verweisen, die mit dem Profil reisen. Das Support-Archiv eines Clients kann weit mehr enthalten, als das Logfenster zeigt, darunter zwischengespeicherte Profile, von deren Existenz Sie nichts mehr wussten. Screenshots sind das andere häufige Leck, weil ein Terminalfenster mehr zeigt als den Befehl, den Sie teilen wollten.

Lesen Sie die Exportdokumentation und öffnen Sie dann die Datei. Eine als Diagnose bezeichnete Ausgabe ist nicht zwangsläufig von irgendetwas bereinigt.

Redigieren, dann eine geprüfte Kopie senden

Bewahren Sie das Original an einem geschützten Ort auf und senden Sie eine geprüfte Kopie. Ersetzen Sie Endpunkte und öffentliche Schlüssel durch stabile Platzhalter, wenn die echten Werte nicht gebraucht werden, und entfernen Sie Blöcke mit privaten Schlüsseln ganz, statt sie teilweise zu verdecken. Teilweise Verdeckung eines base64-Blocks ist immer noch ein geleakter Schlüssel. Lesen Sie die Datei noch einmal, bevor sie hinausgeht, denn Archive tragen oft eine zweite Kopie desselben Profils.

Nutzen Sie einen verifizierten Kanal und prüfen Sie, wer ihn erhält, bevor Sie etwas anhängen.

Wenn ein Schlüssel bereits geleakt ist

Das Löschen der Nachricht holt die Kopien nicht zurück, die andere bereits haben. Rotieren Sie die Identität über den Widerrufs- und Ersetzungsprozess des Betreibers und behandeln Sie den alten Schlüssel ab dem Moment als kompromittiert, in dem er gesendet wurde. Die meisten Betreiber ersetzen eine Client-Identität schnell, sobald die Offenlegung gemeldet ist, und die Meldung ist der Teil, den Leute aufschieben.

Dieselbe Regel gilt für einen Schlüssel, der in ein Ticket, einen Screenshot oder einen Chatverlauf eingefügt wurde. Rotation ist die Lösung; Löschen ist Hausarbeit.