Compresión en OpenVPN: rechazar, solo recibir o LZO completo?

Tres líneas de un perfil parecen desactivar todas la compresión, y solo una lo hace de verdad. La diferencia importa porque el aviso que quiere silenciar es un síntoma, mientras que la política es lo que decide si el otro extremo todavía puede comprimir. Comparar las opciones en un solo eje, es decir, qué permite cada una después del cambio, elimina buena parte de la ambigüedad. Cuál quiera depende de si está migrando o asentándose.

Tres políticas que parecen iguales en un archivo de configuración

Cada opción responde a una pregunta distinta. allow-compression no rechaza las cargas comprimidas de plano, allow-compression asym descomprime lo que llega y nunca comprime lo que sale, y la antigua comp-lzo no deja espacio para que un push del otro extremo active la compresión. Solo la primera es una política que un servidor no puede anular.

Escriba las tres en una tabla antes de elegir, porque los nombres son lo bastante parecidos para engañar a un revisor. Dos de ellas siguen ejecutando código de descompresión en los paquetes recibidos, y de eso trata justamente el argumento de seguridad. La tercera elimina la capacidad en lugar de restringir su dirección. Si el registro del cambio dice que la compresión está desactivada, exactamente una fila cumple esa frase.

El aviso que inició la investigación no es el objetivo. Silenciarlo mientras se mantiene una política permisiva da un registro limpio y una exposición sin cambios.

Qué significa no en la antigua opción LZO

En la opción LZO obsoleta, no desactiva la compresión del lado local sin impedir que el otro extremo la active donde la política lo permite. Esa asimetría explica por qué pasar un perfil a un rechazo estricto cambia el comportamiento de formas que una prueba de laboratorio con un solo servidor quizá nunca revele.

La preocupación de seguridad es condicional, no absoluta. Cuando un atacante puede colocar texto plano elegido junto a un secreto y observar cómo la compresión cambia el tamaño del tráfico cifrado, existe un canal de información. Pasar de LZO a LZ4 cambia el algoritmo y el encuadre, no ese mecanismo.

Así que el planteamiento honesto trata de qué está dispuesto a permitir, no de qué algoritmo se recomienda ahora. El rechazo estricto es la única opción que no depende de la cooperación del otro extremo.

Solo recibir es un estado de migración, no un destino

La aceptación asimétrica existe para que un extremo pueda dejar de comprimir mientras el otro todavía lo espera. Es un puente, y los puentes necesitan una fecha de fin y un responsable. Anote qué pares siguen enviando tráfico comprimido, porque la política permite exactamente ese tráfico. Sin esa lista, el estado de migración se convierte en la configuración permanente por inercia.

Un cliente no puede obligar a un servidor incompatible a abandonar el encuadre antiguo editando su propio archivo. La dirección del push se decide en el servidor, así que la configuración del servidor y sus archivos por cliente son donde la migración termina de verdad.

Los modos stub conservan el encuadre pero se saltan el trabajo de compresión, y no son un equivalente directo de la opción anterior. Pruébelos contra el par más antiguo que aún deba soportar antes de decidirse por uno.

Dónde la descarga del canal de datos cambia la respuesta

La descarga del canal de datos lleva el procesamiento de paquetes al kernel, y un perfil que aún depende del encuadre de compresión puede no encajar en esa ruta. El fallo no siempre es ruidoso: un cliente se conecta y luego se comporta distinto del túnel que probó.

Compruebe qué implementación está activa antes y después del cambio, no solo si la conexión tiene éxito. Cuando la ruta con descarga rechaza el encuadre de compresión, una política de rechazo estricto y un despliegue con descarga coinciden, mientras que una política permisiva y un despliegue con descarga no.

Esa combinación merece su propia prueba, porque es justo donde un archivo que parece correcto, en silencio, no es el que se usa. Compare el estado negociado con la intención registrada en el perfil, porque solo uno de los dos es visible en un registro.

Elija una política y luego verifique el resultado negociado

Elija rechazo estricto cuando pueda cambiar ambos extremos, aceptación asimétrica cuando aún no pueda, y compresión completa solo cuando pueda explicar por qué la exposición es aceptable. Luego verifique lo negociado en lugar de lo que dice el archivo. Un registro más silencioso solo es prueba cuando coincide con la política que pretendía desplegar.

Mantenga la decisión junto al perfil al que se aplica, con la fecha y los pares aún exentos. Seis meses después, esa nota es la diferencia entre una excepción deliberada y un accidente que nadie puede fechar. Escríbala en el mismo repositorio que el perfil para que el siguiente editor vea el motivo antes de la directiva.