OpenVPN-Kompression: ablehnen, nur empfangen oder volles LZO?

Drei Zeilen in einem Profil sehen so aus, als würden alle die Kompression abschalten, und nur eine davon tut es tatsächlich. Der Unterschied zählt, weil die Warnung, die Sie zum Schweigen bringen wollen, ein Symptom ist, während die Richtlinie entscheidet, ob die Gegenseite noch komprimieren darf. Vergleicht man die Optionen auf einer Achse, nämlich was jede nach der Änderung erlaubt, verschwindet der größte Teil der Unklarheit. Welche Sie wollen, hängt davon ab, ob Sie migrieren oder sich einrichten.

Drei Richtlinien, die in einer Konfigurationsdatei ähnlich aussehen

Jede Option beantwortet eine andere Frage. allow-compression no lehnt komprimierte Nutzdaten rundweg ab, allow-compression asym dekomprimiert, was ankommt, und komprimiert nie, was hinausgeht, und das alte comp-lzo no lässt Raum für einen Push der Gegenseite, der die Kompression einschaltet. Nur die erste ist eine Richtlinie, die ein Server nicht überstimmen kann.

Schreiben Sie die drei vor der Wahl in eine Tabelle, denn die Namen liegen nah genug beieinander, um eine Prüferin in die Irre zu führen. Zwei davon führen auf empfangenen Paketen noch Dekomprimierungscode aus, und genau darum geht es im Sicherheitsargument. Die dritte entfernt die Fähigkeit, statt ihre Richtung einzuschränken. Wenn der Änderungseintrag sagt, die Kompression sei deaktiviert, erfüllt genau eine Zeile diesen Satz.

Die Warnung, die die Untersuchung ausgelöst hat, ist nicht das Ziel. Sie zum Schweigen zu bringen und dabei eine freizügige Richtlinie stehen zu lassen, ergibt ein sauberes Protokoll und eine unveränderte Exposition.

Was no bei der alten LZO-Option bedeutet

Bei der veralteten LZO-Option schaltet no die Kompression für die lokale Seite ab, ohne der Gegenseite zu verbieten, sie dort einzuschalten, wo die Richtlinie es zulässt. Diese Asymmetrie ist der Grund, warum der Wechsel eines Profils zu einer strikten Ablehnung das Verhalten auf Arten ändert, die ein Labortest mit einem einzigen Server möglicherweise nie zeigt.

Das Sicherheitsbedenken ist bedingt, nicht absolut. Wenn ein Angreifer gewählten Klartext neben ein Geheimnis legen und beobachten kann, wie die Kompression die Größe verschlüsselten Verkehrs verändert, existiert ein Informationskanal. Der Wechsel von LZO zu LZ4 ändert den Algorithmus und die Rahmung, nicht diesen Mechanismus.

Die ehrliche Einordnung betrifft also, was Sie zuzulassen bereit sind, nicht, welcher Algorithmus gerade empfohlen wird. Strikte Ablehnung ist die einzige Option, die nicht von der Mitarbeit der anderen Seite abhängt.

Nur Empfangen ist ein Migrationszustand, kein Ziel

Asymmetrische Annahme gibt es, damit eine Seite aufhören kann zu komprimieren, während die andere es noch erwartet. Sie ist eine Brücke, und Brücken brauchen ein Enddatum und einen Verantwortlichen. Notieren Sie, welche Gegenstellen noch komprimierten Verkehr senden, denn die Richtlinie erlaubt genau diesen Verkehr. Ohne diese Liste wird der Migrationszustand durch Trägheit zur dauerhaften Konfiguration.

Ein Client kann einen inkompatiblen Server nicht dazu zwingen, die alte Rahmung aufzugeben, indem er seine eigene Datei ändert. Die Push-Richtung wird auf dem Server entschieden, also endet die Migration tatsächlich in der Serverkonfiguration und deren Dateien pro Client.

Stub-Modi bewahren die Rahmung und überspringen die Kompressionsarbeit selbst, und sie sind kein direkter Ersatz für die ältere Option. Testen Sie sie gegen die älteste Gegenstelle, die Sie noch unterstützen müssen, bevor Sie sich für eine entscheiden.

Wo Offload des Datenkanals die Antwort ändert

Offload des Datenkanals verlagert die Paketverarbeitung in den Kernel, und ein Profil, das noch von Kompressionsrahmung abhängt, passt möglicherweise nicht auf den ausgelagerten Pfad. Der Fehler ist nicht immer laut: Ein Client verbindet sich und verhält sich dann anders als der getestete Tunnel.

Prüfen Sie, welche Implementierung vor und nach der Änderung aktiv ist, nicht nur, ob die Verbindung gelingt. Wenn der ausgelagerte Pfad Kompressionsrahmung ablehnt, stimmen eine strikte Ablehnungsrichtlinie und ein ausgelagertes Deployment überein, eine freizügige Richtlinie und ein ausgelagertes Deployment dagegen nicht.

Diese Kombination verdient einen eigenen Test, denn genau dort ist eine Datei, die korrekt aussieht, stillschweigend nicht die verwendete. Vergleichen Sie den ausgehandelten Zustand mit der im Profil festgehaltenen Absicht, denn nur einer von beiden ist in einem Protokoll sichtbar.

Wählen Sie eine Richtlinie und prüfen Sie dann das ausgehandelte Ergebnis

Wählen Sie strikte Ablehnung, wenn Sie beide Seiten ändern können, asymmetrische Annahme, wenn noch nicht, und volle Kompression nur, wenn Sie begründen können, warum die Exposition vertretbar ist. Prüfen Sie dann, was ausgehandelt wurde, statt was in der Datei steht. Ein stilleres Protokoll ist nur dann ein Beleg, wenn es zur beabsichtigten Richtlinie passt.

Halten Sie die Entscheidung neben dem Profil, für das sie gilt, mit Datum und den weiterhin ausgenommenen Gegenstellen. Ein halbes Jahr später ist diese Notiz der Unterschied zwischen einer bewussten Ausnahme und einem Unfall, den niemand datieren kann. Schreiben Sie sie in dasselbe Repository wie das Profil, damit die nächste Bearbeitung den Grund vor der Anweisung sieht.