Compressió d'OpenVPN: rebutjar, només rebre o LZO complet?
comp-lzo no no és un rebuig estricte. Compareu rebutjar la compressió, acceptar-la en un sol sentit durant la migració i mantenir-la, i després comproveu què fa l'offload.
Tres línies d'un perfil semblen desactivar totes la compressió, i només una ho fa de debò. La diferència importa perquè l'avís que voleu silenciar és un símptoma, mentre que la política és el que decideix si l'altre extrem encara pot comprimir. Comparar les opcions en un sol eix, és a dir, què permet cadascuna després del canvi, elimina bona part de l'ambigüitat. Quina voleu depèn de si esteu migrant o us instal·leu.
Tres polítiques que semblen iguals en un fitxer de configuració
Cada opció respon una pregunta diferent. allow-compression no rebutja les càrregues comprimides de manera directa, allow-compression asym descomprimeix el que arriba i no comprimeix mai el que surt, i l'antiga comp-lzo no deixa espai perquè un push de l'altre extrem activi la compressió. Només la primera és una política que un servidor no pot anul·lar.
Poseu les tres en una taula abans de triar, perquè els noms són prou propers per enganyar un revisor. Dues d'elles encara executen codi de descompressió als paquets rebuts, i és precisament d'això que tracta l'argument de seguretat. La tercera elimina la capacitat en lloc de restringir-ne la direcció. Si el registre del canvi diu que la compressió està desactivada, exactament una fila compleix aquesta frase.
L'avís que va iniciar la investigació no és l'objectiu. Silenciar-lo mentre es manté una política permissiva dona un registre net i una exposició inalterada.
| 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 |
Què significa no a l'antiga opció LZO
A l'opció LZO obsoleta, no desactiva la compressió per al costat local sense impedir que l'altre extrem l'activi allà on la política ho permet. Aquesta asimetria explica per què passar un perfil a un rebuig estricte canvia el comportament de maneres que una prova de laboratori amb un sol servidor potser no revelarà mai.
La preocupació de seguretat és condicional, no absoluta. Quan un atacant pot col·locar text pla triat al costat d'un secret i observar com la compressió canvia la mida del trànsit xifrat, existeix un canal d'informació. Passar de LZO a LZ4 canvia l'algorisme i l'emmarcat, no aquest mecanisme.
Així, l'enfocament honest tracta de què esteu disposats a permetre, no de quin algorisme es recomana ara. El rebuig estricte és l'única opció que no depèn de la cooperació de l'altre extrem.
Només rebre és un estat de migració, no una destinació
L'acceptació asimètrica existeix perquè un extrem pugui deixar de comprimir mentre l'altre encara ho espera. És un pont, i els ponts necessiten una data de final i un responsable. Anoteu quins parells encara envien trànsit comprimit, perquè la política permet exactament aquest trànsit. Sense aquesta llista, l'estat de migració es converteix en la configuració permanent per inèrcia.
Un client no pot obligar un servidor incompatible a abandonar l'emmarcat antic editant el seu propi fitxer. La direcció del push es decideix al servidor, així que la configuració del servidor i els seus fitxers per client són on la migració acaba de veritat.
Els modes stub conserven l'emmarcat però s'estalvien la feina de compressió, i no són un equivalent directe de l'opció antiga. Proveu-los amb el parell més antic que encara hàgiu de suportar abans de decidir-vos per un.
On l'offload del canal de dades canvia la resposta
L'offload del canal de dades porta el processament de paquets al nucli, i un perfil que encara depèn de l'emmarcat de compressió potser no encaixa en aquest camí. La fallada no sempre és sorollosa: un client es connecta i després es comporta diferent del túnel que vau provar.
Comproveu quina implementació està activa abans i després del canvi, no només si la connexió té èxit. Quan el camí amb offload refusa l'emmarcat de compressió, una política de rebuig estricte i un desplegament amb offload coincideixen, mentre que una política permissiva i un desplegament amb offload no.
Aquesta combinació mereix una prova pròpia, perquè és exactament on un fitxer que sembla correcte no és en silenci el que s'utilitza. Compareu l'estat negociat amb la intenció registrada al perfil, perquè només un dels dos és visible en un registre.
Trieu una política i després verifiqueu el resultat negociat
Trieu rebuig estricte quan pugueu canviar els dos extrems, acceptació asimètrica quan encara no pugueu, i compressió completa només quan pugueu explicar per què l'exposició és acceptable. Després verifiqueu què s'ha negociat i no què diu el fitxer. Un registre més tranquil només és evidència quan coincideix amb la política que volíeu desplegar.
Manteniu la decisió al costat del perfil al qual s'aplica, amb la data i els parells encara exempts. Sis mesos després, aquesta nota és la diferència entre una excepció deliberada i un accident que ningú no pot datar. Escriviu-la al mateix repositori que el perfil perquè el proper editor vegi el motiu abans de la directiva.