Compression OpenVPN : refuser, recevoir seulement ou LZO complet ?
comp-lzo no n'est pas un refus strict. Comparez le refus de la compression, l'acceptation dans un seul sens pendant une migration et son maintien, puis vérifiez ce que fait le déchargement vers le noyau.
Trois lignes d'un profil semblent toutes désactiver la compression, et une seule le fait réellement. La différence compte, car l'avertissement que vous voulez faire taire est un symptôme, tandis que la politique décide si l'autre extrémité peut encore comprimer. Comparer les options sur un seul axe, à savoir ce que chacune autorise après le changement, lève l'essentiel de l'ambiguïté. Celle que vous voulez dépend de si vous migrez ou si vous vous installez.
Trois politiques qui se ressemblent dans un fichier de configuration
Chaque option répond à une question différente. allow-compression no refuse d'emblée les charges utiles compressées, allow-compression asym décompresse ce qui arrive et ne compresse jamais ce qui sort, et l'ancienne comp-lzo no laisse la place à un push de l'autre extrémité pour activer la compression. Seule la première est une politique qu'un serveur ne peut pas contourner.
Écrivez les trois dans un tableau avant de choisir, car les noms sont assez proches pour induire un relecteur en erreur. Deux d'entre elles exécutent encore du code de décompression sur les paquets reçus, et c'est précisément l'objet de l'argument de sécurité. La troisième retire la capacité au lieu d'en restreindre le sens. Si le compte rendu de changement dit que la compression est désactivée, exactement une ligne satisfait cette phrase.
L'avertissement qui a déclenché l'enquête n'est pas l'objectif. Le faire taire en laissant une politique permissive donne un journal propre et une exposition inchangée.
| Setting | What it permits | When it is the right answer |
|---|---|---|
allow-compression no | No compressed payloads, and no compression framing under offload | Both ends can be changed now |
allow-compression asym | Decompress inbound only | A dated migration while peers catch up |
comp-lzo no | Off locally, still pushable by a peer | Legacy compatibility you can still justify |
Ce que no signifie pour l'ancienne option LZO
Sur l'option LZO obsolète, no désactive la compression côté local sans interdire à l'autre extrémité de l'activer là où la politique le permet. C'est cette asymétrie qui fait qu'un passage à un refus strict change le comportement d'une manière qu'un test en laboratoire avec un seul serveur ne révélera peut-être jamais.
La préoccupation de sécurité est conditionnelle, pas absolue. Quand un attaquant peut placer un texte clair choisi à côté d'un secret et observer comment la compression modifie la taille du trafic chiffré, un canal d'information existe. Passer de LZO à LZ4 change l'algorithme et l'encapsulation, pas ce mécanisme.
Le cadrage honnête porte donc sur ce que vous acceptez d'autoriser, non sur l'algorithme actuellement recommandé. Le refus strict est la seule option qui ne dépende pas de la coopération de l'autre extrémité.
Recevoir seulement est un état de migration, pas une destination
L'acceptation asymétrique existe pour qu'une extrémité cesse de comprimer pendant que l'autre l'attend encore. C'est un pont, et un pont a besoin d'une date de fin et d'un responsable. Notez quels pairs envoient encore du trafic compressé, car la politique autorise exactement ce trafic. Sans cette liste, l'état de migration devient la configuration permanente par inertie.
Un client ne peut pas forcer un serveur incompatible à abandonner l'ancienne encapsulation en modifiant son propre fichier. Le sens du push se décide sur le serveur, donc la migration s'achève réellement dans la configuration du serveur et ses fichiers par client.
Les modes stub conservent l'encapsulation tout en sautant le travail de compression lui-même, et ils ne sont pas un équivalent direct de l'ancienne option. Testez-les contre le pair le plus ancien que vous devez encore prendre en charge avant de vous engager sur l'un d'eux.
Où le déchargement du canal de données change la réponse
Le déchargement du canal de données déplace le traitement des paquets dans le noyau, et un profil qui dépend encore de l'encapsulation de compression peut ne pas convenir à ce chemin. L'échec n'est pas toujours bruyant : un client se connecte puis se comporte différemment du tunnel que vous avez testé.
Vérifiez quelle implémentation est active avant et après le changement, pas seulement si la connexion réussit. Quand le chemin déchargé refuse l'encapsulation de compression, une politique de refus strict et un déploiement déchargé s'accordent, alors qu'une politique permissive et un déploiement déchargé ne s'accordent pas.
Cette combinaison mérite son propre test, car c'est exactement là qu'un fichier qui semble correct n'est silencieusement pas celui utilisé. Comparez l'état négocié à l'intention consignée dans le profil, car une seule des deux est visible dans un journal.
Choisissez une politique, puis vérifiez le résultat négocié
Choisissez le refus strict quand vous pouvez changer les deux extrémités, l'acceptation asymétrique quand ce n'est pas encore possible, et la compression complète seulement quand vous pouvez expliquer pourquoi l'exposition est acceptable. Vérifiez ensuite ce qui a été négocié plutôt que ce que dit le fichier. Un journal plus silencieux n'est une preuve que s'il correspond à la politique que vous comptiez déployer.
Gardez la décision à côté du profil auquel elle s'applique, avec la date et les pairs encore exemptés. Six mois plus tard, cette note fait la différence entre une exception délibérée et un accident que personne ne peut dater. Écrivez-la dans le même dépôt que le profil pour que le prochain éditeur voie la raison avant la directive.