Compresión en OpenVPN: rexeitar, só recibir ou LZO completo?
comp-lzo no non é un rexeitamento estrito. Compare rexeitar a compresión, aceptala nun só sentido durante unha migración e mantela, e despois comprobe que fai a descarga ao núcleo.
Tres liñas dun perfil parecen desactivar todas a compresión, e só unha o fai de verdade. A diferenza importa porque o aviso que quere silenciar é un síntoma, mentres que a política é o que decide se o outro extremo aínda pode comprimir. Comparar as opcións nun só eixo, é dicir, que permite cada unha despois do cambio, elimina boa parte da ambigüidade. Cal queira depende de se está migrando ou asentándose.
Tres políticas que parecen iguais nun ficheiro de configuración
Cada opción responde a unha pregunta distinta. allow-compression no rexeita as cargas comprimidas de plano, allow-compression asym descomprime o que chega e nunca comprime o que sae, e a antiga comp-lzo no deixa espazo para que un push do outro extremo active a compresión. Só a primeira é unha política que un servidor non pode anular.
Escriba as tres nunha táboa antes de escoller, porque os nomes son o bastante parecidos para enganar a un revisor. Dúas delas seguen executando código de descompresión nos paquetes recibidos, e diso trata xustamente o argumento de seguridade. A terceira elimina a capacidade en lugar de restrinxir a súa dirección. Se o rexistro do cambio di que a compresión está desactivada, exactamente unha fila cumpre esa frase.
O aviso que iniciou a investigación non é o obxectivo. Silencialo mentres se mantén unha política permisiva dá un rexistro limpo e unha exposición sen cambios.
| 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 |
Que significa no na antiga opción LZO
Na opción LZO obsoleta, no desactiva a compresión do lado local sen impedir que o outro extremo a active onde a política o permite. Esa asimetría explica por que pasar un perfil a un rexeitamento estrito cambia o comportamento de formas que unha proba de laboratorio cun só servidor quizais nunca revele.
A preocupación de seguridade é condicional, non absoluta. Cando un atacante pode colocar texto plano escollido xunto a un segredo e observar como a compresión cambia o tamaño do tráfico cifrado, existe unha canle de información. Pasar de LZO a LZ4 cambia o algoritmo e a empaquetadura, non ese mecanismo.
Así que o enfoque honesto trata de que está disposto a permitir, non de que algoritmo se recomenda agora. O rexeitamento estrito é a única opción que non depende da cooperación do outro extremo.
Só recibir é un estado de migración, non un destino
A aceptación asimétrica existe para que un extremo poida deixar de comprimir mentres o outro aínda o espera. É unha ponte, e as pontes necesitan unha data de fin e un responsable. Anote que pares seguen enviando tráfico comprimido, porque a política permite exactamente ese tráfico. Sen esa lista, o estado de migración convértese na configuración permanente por inercia.
Un cliente non pode obrigar un servidor incompatible a abandonar a empaquetadura antiga editando o seu propio ficheiro. A dirección do push decídese no servidor, así que a configuración do servidor e os seus ficheiros por cliente son onde a migración remata de verdade.
Os modos stub conservan a empaquetadura pero saltan o traballo de compresión, e non son un equivalente directo da opción anterior. Próbeos contra o par máis antigo que aínda deba soportar antes de decidirse por un.
Onde a descarga do canal de datos cambia a resposta
A descarga do canal de datos leva o procesamento de paquetes ao núcleo, e un perfil que aínda depende da empaquetadura de compresión pode non encaixar nesa ruta. O fallo non sempre é ruidoso: un cliente conéctase e logo compórtase distinto do túnel que probou.
Comprobe que implementación está activa antes e despois do cambio, non só se a conexión ten éxito. Cando a ruta con descarga rexeita a empaquetadura de compresión, unha política de rexeitamento estrito e unha implantación con descarga coinciden, mentres que unha política permisiva e unha implantación con descarga non.
Esa combinación merece a súa propia proba, porque é xusto onde un ficheiro que parece correcto, en silencio, non é o que se usa. Compare o estado negociado coa intención rexistrada no perfil, porque só un dos dous é visible nun rexistro.
Escolla unha política e logo verifique o resultado negociado
Escolla rexeitamento estrito cando poida cambiar ambos extremos, aceptación asimétrica cando aínda non poida, e compresión completa só cando poida explicar por que a exposición é aceptable. Logo verifique o negociado en lugar do que di o ficheiro. Un rexistro máis silencioso só é proba cando coincide coa política que pretendía implantar.
Manteña a decisión xunto ao perfil ao que se aplica, coa data e os pares aínda exentos. Seis meses despois, esa nota é a diferenza entre unha excepción deliberada e un accidente que ninguén pode datar. Escríbaa no mesmo repositorio que o perfil para que o seguinte editor vexa o motivo antes da directiva.