Muchas pequeñas empresas usan un servidor OpenVPN que alguien configuró hace años y que nadie ha vuelto a tocar. Sigue funcionando hasta que se actualiza el sistema operativo del servidor o llega una laptop nueva con el cliente más reciente, y de pronto algunos usuarios, o todos, no pueden conectarse. Debian 12 y 13 y Ubuntu 24.04 incluyen la serie OpenVPN 2.6, compilada con OpenSSL 3, y juntas eliminan varios valores predeterminados antiguos. Esta guía explica qué suele fallar en una actualización de OpenVPN 2.6, cómo corregirlo bien en lugar de reactivar las opciones viejas y qué más revisar mientras la configuración está abierta.

Cifrados: de cipher a OpenVPN data-ciphers

Las configuraciones antiguas suelen contener una línea como cipher BF-CBC o cipher AES-256-CBC, o no dicen nada y dependen del antiguo valor predeterminado Blowfish. Desde la versión 2.5, OpenVPN negocia el cifrado del canal de datos a partir de una lista definida con la opción OpenVPN data-ciphers y, de forma predeterminada, acepta AES-256-GCM y AES-128-GCM, además de CHACHA20-POLY1305 en la 2.6 cuando la biblioteca criptográfica lo admite. La opción cipher ya no se agrega automáticamente a esa lista. Los clientes muy antiguos que no pueden negociar, o los servidores que siguen configurados solo para Blowfish, no logran conectarse.

OpenSSL 3 añade una segunda barrera: ya no ofrece Blowfish ni otros algoritmos heredados a menos que se cargue explícitamente su proveedor legacy. Esa opción existe como puente temporal, no como destino. La solución duradera es actualizar los clientes y dejar que ambos lados negocien AES-GCM o ChaCha20.

La compresión viene desactivada

Las configuraciones de la época de las versiones 2.3 y 2.4 incluyen con frecuencia comp-lzo o una línea compress. La compresión combinada con el cifrado puede filtrar información sobre el tráfico, lo que se conoce como el ataque VORACLE, por lo que la compresión de OpenVPN se desaconseja desde hace años. En la 2.6, allow-compression es no de forma predeterminada, salvo que la configuración mencione la compresión de manera explícita. Si los ajustes del servidor y del cliente no coinciden, el resultado son túneles que se conectan y luego no pasan tráfico. La solución limpia es quitar la compresión del servidor y de cada perfil de cliente. Si algunos clientes no pueden actualizarse de inmediato, mantenga un ajuste explícito y asimétrico solo durante una transición breve.

Certificados, claves y "CRL has expired"

Durante una actualización suelen aparecer tres problemas con los certificados:

  • Claves y firmas antiguas y débiles. OpenSSL 3, tal como se configura en Debian y Ubuntu, rechaza las claves RSA de menos de 2048 bits y los certificados firmados con algoritmos hash obsoletos. Una autoridad certificadora creada hace diez años con claves pequeñas debe reemplazarse, y cada usuario necesita un perfil nuevo.
  • Certificados por vencer. Las versiones actuales de easy-rsa emiten certificados de servidor y de cliente con una vigencia limitada. Averigüe las fechas de vencimiento ahora, no la mañana en que caduquen.
  • Una lista de revocación vencida. Si el servidor usa crl-verify, la lista de revocación de certificados tiene su propio vencimiento, de 180 días de forma predeterminada en easy-rsa. Cuando pasa esa fecha, todos los clientes fallan con "CRL has expired", aunque nada más haya cambiado. Regenérela con easyrsa gen-crl, cópiela donde la lee el servidor y programe la renovación para que no vuelva a ocurrir.

Refuerzo de seguridad del servidor OpenVPN ya que está en ello

Una actualización es un buen momento para agregar los ajustes que faltan en las configuraciones antiguas:

  • tls-crypt, o tls-crypt-v2 con una clave distinta para cada cliente, cifra y autentica el canal de control, de modo que el servidor no responde a nadie que no tenga la clave. Oculta el servidor de los escaneos y reduce los intentos de denegación de servicio.
  • Una versión mínima de TLS 1.2 para el canal de control.
  • Certificados por usuario más un segundo factor, para que un perfil copiado por sí solo no pueda conectarse.
  • Reglas de firewall por grupo, para que el perfil de un contratista llegue a una aplicación y no a toda la red de la oficina.
  • Descarga del canal de datos (data channel offload) en Linux, novedad de la 2.6, que traslada el cifrado de paquetes al kernel para obtener mayor rendimiento en servidores con mucha carga.

Cada opción y su valor predeterminado actual aparecen en el manual de referencia de OpenVPN 2.6, que conviene tener abierto durante el trabajo.

Cómo actualizar OpenVPN 2.6 sin una caída el lunes por la mañana

  1. Copie la configuración del servidor actual, las claves y los perfiles de cliente a un lugar seguro.
  2. Haga una lista de todos los clientes en uso: sistema operativo, versión del cliente y a quién pertenece.
  3. Cree la nueva configuración en una instancia de prueba o en un segundo puerto y conecte un cliente actualizado de cada tipo.
  4. Emita perfiles nuevos donde cambien los certificados o los cifrados y envíe a los usuarios instrucciones breves para la configuración de clientes OpenVPN en sus dispositivos.
  5. Haga el cambio en un momento tranquilo y mantenga listo el servidor anterior para volver atrás hasta que todos se hayan conectado.

Para una instalación de VPN en Linux desde cero, esta misma lista se convierte en el diseño: cifrados modernos, sin compresión, tls-crypt y certificados con una lista de revocación que se renueva sola. Si prefiere delegar el trabajo, nuestro servicio de configuración de OpenVPN abarca la autoridad certificadora, las reglas de firewall y los perfiles de cliente.

Preguntas frecuentes: actualización de OpenVPN 2.6

¿Los usuarios necesitan perfiles nuevos después de la actualización?

Solo si cambia algo de lo que tienen: una nueva autoridad certificadora, certificados nuevos, una clave tls-crypt o ajustes de cifrado distintos. Quitar la compresión suele implicar editar también el perfil, por eso muchas actualizaciones terminan con perfiles nuevos para todos.

¿Cómo evitamos que la CRL vuelva a vencer?

Programe easyrsa gen-crl con bastante margen dentro de la vigencia de la CRL, copie el archivo nuevo a la ruta indicada en crl-verify y configure una alerta cuando se acerque su fecha de próxima actualización. Las versiones actuales vuelven a leer el archivo cuando cambia, así que no hace falta reiniciar, pero debe poder leerlo el usuario con el que se ejecuta el servidor OpenVPN.

¿Pueden seguir funcionando los clientes antiguos durante la transición?

Por un tiempo breve, sí, permitiendo de forma explícita sus cifrados o su compresión en el servidor. Trátelo como un plazo, no como un ajuste permanente.

¿Clientes que fallan tras una actualización, o un servidor OpenVPN que nadie revisa desde hace años? Nuestro servicio de instalación y configuración de OpenVPN abarca el refuerzo de seguridad, los certificados y los perfiles por usuario para Windows, macOS, Linux y dispositivos móviles, y como servicio de configuración de VPN se integra en un trabajo más amplio de seguridad de red y VPN para oficinas en Long Beach y Los Ángeles. Contáctenos con la versión del sistema operativo del servidor y las versiones de cliente que usa su equipo.