Ein VPN-Protokoll redigieren, ohne die wichtigen Hinweise zu verlieren

Du fügst ein Protokoll in einen Support-Thread ein, eine Antwort weist darauf hin, dass es deinen privaten Schlüssel enthält, und das Einfügen ist dauerhaft. Der leisere Fehler zeigt sich später, wenn jede Adresse zu X geworden ist und die Datei nicht mehr belegt, dass Client und Server verschiedene Hosts waren. Ein Redaktionsdurchgang entfernt, was Zugang gewährt oder eine Person benennt, und behält, was den Fehler erklärt. Das ist eine Umformung mit Regeln, keine Löschung mit einem Suchfeld.

Redigieren ist eine Umformung, keine Löschung

Ein Protokoll trägt Struktur ebenso wie Werte: Diese Adresse sprach zu dieser Zeit mit jener, und der Handshake blieb an diesem Schritt stehen. Die Werte sind es, die die Datei gefährlich zu veröffentlichen machen. Die Struktur ist es, die sie überhaupt veröffentlichungswert macht.

Ganze Zeilen zu löschen entfernt beides zugleich, weshalb ein gekürztes Protokoll oft nichts beantwortet. Alle Werte in ein einziges Token zusammenzufassen scheitert anders, weil zwei verschiedene Peers zu einem einzigen Akteur werden. Beide Durchgänge können ordentlich aussehen und trotzdem den Beweis zerstören. Der Test ist, ob ein Leser, der dein Netzwerk nie gesehen hat, der Abfolge folgen und zu deinem Schluss kommen kann.

Erst Auszug, dann schwärzen

Schneide den Abschnitt um den Fehler heraus, bevor du irgendetwas bearbeitest. Ein kleinerer Auszug ist leichter zu prüfen und trägt seltener etwas mit, von dem du vergessen hattest, dass es in der Datei war. Bewahre das unberührte Original bis zum Abschluss des Falls in geschütztem Speicher auf. Redigieren ist verlustbehaftet, und die Rohdatei ist der einzige Weg, die Rückfrage zu beantworten.

Lies den Auszug als Klartext, bevor du einem Exportbefehl zutraust, die privaten Teile entfernt zu haben, denn Exporteure fassen Felder zusammen und rotieren sie, statt sie zu bereinigen. Debug- und Verbose-Modus sind der wahrscheinlichste Ort für einen Schlüsselblock oder eine eingebettete Zugangsangabe. Öffne die Datei in einem Editor, der volle Zeilen zeigt, nicht in einem Betrachter, der umbricht und das Ende verbirgt.

Was weg muss, und in welcher Reihenfolge

Beginne mit Material, das Zugang gewährt, denn ein Treffer, der dort fehlt, beendet die Übung: Blöcke mit privaten Schlüsseln, Passwörter, vorab geteilte Schlüssel, API-Token, Wiederherstellungscodes. Diese sind nicht bloß identifizierend; sie sind für jeden nutzbar, der den Thread liest. Ein Durchgang, der alles andere entfernt und eines davon stehen lässt, ist gescheitert.

Dann die Identitätsebene: Benutzernamen, Zertifikatsubjekte und Seriennummern, Kontokennungen und jeder Pfad, der den Namen einer Person enthält. Nichts davon ist allein verwendbar, aber zusammen benennt es eine Person, und das ist der Teil, den ein öffentlicher Thread nicht braucht.

Dann die Topologieebene, und hier kommt das Urteilsvermögen ins Spiel. Öffentliche Adressen, interne Bereiche und Hostnamen lassen sich alle ersetzen, wenn ihre Offenlegung keinem diagnostischen Zweck dient, und stabile Kennungen sind besser als Leerstellen. Die Reihenfolge zählt, weil die früheren Ebenen absolut sind und die letzte eine Entscheidung ist. In dieser Reihenfolge zu arbeiten hindert dich auch daran, eine Stunde mit Hostnamen zu verbringen, während ein Schlüsselblock in Zeile vierzig steht.

Zerstöre nicht die Beziehungen

Gib jedem echten Wert einen Platzhalter und verwende ihn jedes Mal wieder, wenn dieser Wert erscheint. Waren zwei Adressen verschieden, müssen sie es nach dem Durchgang bleiben, sonst schließt der Leser, der Client habe sich mit sich selbst verbunden. Konsistenz ist der ganze Mechanismus: Der Leser lernt die Zuordnung, indem er eine Kennung wiederkehren sieht. Ein einziges wiederverwendetes Token für zwei Akteure ist der schnellste Weg, ein Protokoll unlesbar zu machen.

Reihenfolge und Zeit gehören zur selben Struktur. Halte die Abfolge intakt, und wenn du Zeitstempel verschiebst, verschiebe jeden um denselben Betrag und sage es in einer Zeile. Geänderte und echte Zeiten zu mischen ist schlimmer, als sie zu entfernen, denn dann wirken die Lücken wie Belege für etwas, das nie geschah.

Ports, Protokoll und Richtung bleiben, wie sie sind. Ein Platzhalter für die Adresse erfordert keinen Platzhalter für den Port.

Behalte die Frage, die das Protokoll beantworten muss

Schreibe die Felder auf, die ein Helfer braucht, bevor du mit dem Bearbeiten beginnst: den genauen, nicht geheimen Fehlertext, Client- und Serverversionen, das Transportprotokoll und die Seite, die den Versuch ausgelöst hat. Das sind die Dinge, die einen Fremden den Fehler erkennen lassen. Die Liste neben sich zu halten macht den Durchgang zu einer Prüfung statt zu einer Hoffnung.

Wenn du die Datei sendest, füge eine Zeile hinzu, die sagt, was ersetzt wurde, damit niemand eine Stunde mit der Diagnose eines Platzhalter-Hostnamens verbringt. OpenVPNs Dokumentation zum Diagnoseprotokoll führt die Felder auf, die seine Protokolle tragen, und das ist die Liste, die du gerade änderst. Frage, bevor du einen Speicherauszug oder einen Paketmitschnitt sendest, und nutze den Supportkanal, den du überprüfen kannst. Diese Artefakte enthalten weit mehr als das Textprotokoll, und manches davon darfst du nicht veröffentlichen.

Lies den fertigen Auszug einmal von der ersten bis zur letzten Zeile, einschließlich Anfang und Ende. Screenshots verdienen mehr Misstrauen als Text, weil sie andere Fenster, Kontonamen und Menüpunkte mitbringen.