Cómo OpenVPN data-ciphers elige el cifrado del canal de datos

El túnel se levanta, el registro muestra un cifrado y la revisión del perfil continúa. Luego llega una actualización en un par y el mismo perfil falla con un mensaje sobre ningún cifrado compartido, lo que manda a la gente a buscar una directiva que borrar. Lo útil que hay que entender es que data-ciphers describe una negociación, no un ajuste. Un lado ofrece una lista, el otro elige de ella, y el resultado es un solo algoritmo que ambos admiten. Leer ese intercambio explica la mayoría de estos fallos antes de que cambie una línea.

Dos canales, dos configuraciones

Una OpenVPN sesión tiene un canal de control y un canal de datos. El canal de control ejecuta el handshake TLS que autentica a los pares y negocia las claves. El canal de datos cifra los paquetes que llevan su tráfico.

data-ciphers configura el segundo. El canal de control tiene sus propias opciones, y las comprobaciones de identidad del perfil son un tercer asunto, separado. Un cambio en uno no arregla el otro, por lo que un perfil puede parecer correcto y fallar igualmente en una etapa concreta.

Mantenga los tres en cajas separadas cuando lea un archivo de configuración.

Lea la negociación en el registro

El registro del cliente nombra ambos resultados cuando la conexión se establece. Una línea informa del canal de control y sus detalles TLS, y otra informa del cifrado del canal de datos que se seleccionó.

Lea ambos, porque responden a preguntas distintas. Un fallo del canal de control detiene la conexión antes de que importe ningún cifrado de datos. Una discrepancia del canal de datos aparece tras un handshake correcto, con un mensaje sobre ningún cifrado compartido.

Luego compare las listas ofrecidas en ambos lados. Un nombre que la versión de un par o su backend criptográfico no proporciona no se puede seleccionar, por muy pronto que aparezca en la lista del otro par.

Cómo ocurre realmente la selección

El servidor empuja su lista data-ciphers al cliente durante el handshake, y el cliente selecciona la primera entrada de esa lista que también admite. El orden pertenece, por tanto, a la configuración del servidor, no a la del cliente.

Ese detalle explica una clase de resultados confusos. Reordenar la lista del cliente no cambia nada mientras decide la lista del servidor. Añadir un cifrado que el cliente no puede proporcionar tampoco cambia nada, porque el cliente tiene que poder usar la entrada que elige.

Las versiones más recientes cambiaron la lista predeterminada y renombraron la opción que solía contenerla, así que dos pares en versiones distintas pueden discrepar sin que nadie edite un perfil. Compruebe la versión en cada lado antes de suponer una errata.

Una lista no es una clasificación de fuerza en abstracto. Es un conjunto de candidatos, y el seleccionado es la primera entrada mutuamente admitida en el orden del servidor. Por eso dos listas que parecen distintas pueden negociar el mismo cifrado. También por eso dos listas que parecen idénticas pueden fallar.

Los pares más antiguos necesitan un respaldo deliberado

Un par que no puede negociar en absoluto, porque es anterior al mecanismo o lo tiene desactivado, necesita un acuerdo de compatibilidad documentado. La opción de respaldo existe exactamente para ese caso y se aplica a los pares que no participan en la negociación.

Eso no es lo mismo que habilitar todos los cifrados heredados para hacer desaparecer un mensaje. Una lista amplia debilita la sesión para cada par, incluidos los que habrían negociado algo fuerte.

Coordine los dos lados en lugar de editar nombres de algoritmos no relacionados. Si una actualización del servidor eliminó una opción antigua, la corrección pertenece al plan de versiones, no a una carrera en el cliente.

Mantenga intacta la verificación

Una discrepancia del canal de datos no es motivo para aceptar un servidor no verificado. La verificación del certificado, el nombre de servidor esperado y los ajustes de protección del canal de control son independientes de la selección de cifrado y deberían sobrevivir a cualquier cambio de compatibilidad.

Registre juntos el cifrado de datos negociado, la versión del cliente y la versión del servidor, para que la próxima comparación parta de hechos y no del archivo de perfil.

Tras una corrección admitida, pruebe la conexión inicial y una renegociación, porque una sesión que se establece una vez todavía puede fallar cuando se renuevan las claves.

Si el túnel se establece y los sitios siguen fallando, el cifrado ya no es el sospechoso. Continúe con el enrutamiento y el DNS. Orden de trabajo: lea ambas líneas del registro, compare ambas listas, compruebe las versiones, añada un respaldo solo para un par que lo necesite y vuelva a probar la ruta de renovación.