OpenVPN ha publicado la versión 2.7.0 de su veterana solución de red privada virtual (VPN), un lanzamiento que apunta directamente a dos frentes que suelen decidir si una VPN “aguanta” en producción: el rendimiento del canal de datos y la operación diaria (cambios de rutas, DNS, compatibilidad multiplataforma y mantenimiento). En un mercado cada vez más condicionado por modelos Zero Trust, teletrabajo y accesos híbridos, OpenVPN 2.7 llega con mejoras que no se quedan en lo cosmético: incorpora soporte para el nuevo módulo DCO en Linux (Data Channel Offload), añade compatibilidad con mbedTLS 4, avanza en TLS 1.3 con versiones recientes de mbedTLS y, además, introduce mecanismos para actualizar configuración en caliente sin forzar reconexiones.
El resultado es una versión con lectura práctica: menos interrupciones para el usuario final, más control para el administrador y una base técnica pensada para escalar mejor en escenarios reales, donde un servidor no siempre vive con una única IP, un único puerto o una única política de DNS.
DCO en Linux: el rendimiento deja de ser solo “cosa del espacio de usuario”
La gran novedad técnica de OpenVPN 2.7 es el soporte para el módulo DCO en Linux, una pieza diseñada para descargar parte del trabajo del canal de datos hacia el kernel. La idea detrás de DCO es conocida por cualquier responsable de infraestructura: si el tráfico cifrado y encapsulado puede gestionarse con menos “viajes” y menos sobrecarga en espacio de usuario, se abre la puerta a un mejor aprovechamiento de CPU y a un comportamiento más predecible cuando crece el número de clientes o el caudal de la conexión.
OpenVPN 2.7 no promete magia, pero sí marca dirección: alinear la evolución del producto con un enfoque de offload que, además, se integra de forma upstream en Linux y cuenta con backports para quienes no puedan esperar al ciclo normal de kernels en producción.
Multi-socket: una sola instancia, varios endpoints y menos duplicidad operativa
En entornos de empresa, el “servidor VPN” rara vez es un servicio de laboratorio. A menudo necesita convivir con IPv4 e IPv6, atender varias interfaces, o exponerse por diferentes puertos/protocolos para adaptarse a redes restrictivas o políticas corporativas. OpenVPN 2.7 introduce multi-socket en modo servidor, lo que permite gestionar múltiples direcciones, puertos o protocolos dentro de un mismo servidor sin montar configuraciones paralelas.
Este cambio reduce complejidad y, sobre todo, disminuye el riesgo humano: menos ficheros duplicados, menos divergencias involuntarias entre instancias y una visión más centralizada del servicio.
PUSH_UPDATE: cambios de rutas y DNS sin “tirar” el túnel
Otro punto con impacto directo en la experiencia del usuario es el soporte del mensaje de control PUSH_UPDATE. La nueva versión incorpora soporte del lado del cliente para que el servidor pueda enviar actualizaciones de opciones —por ejemplo, rutas o configuración DNS— sin obligar a reconectar. Esto, que suena menor, resuelve un clásico: en muchas organizaciones, un ajuste de enrutado o DNS termina “pareciendo” una caída del servicio para el usuario, cuando en realidad es una actualización legítima de política.
En paralelo, OpenVPN 2.7 añade soporte inicial del lado del servidor, con comandos en la interfaz de gestión para emitir estas actualizaciones de forma amplia o dirigida a clientes concretos. El beneficio es claro: menos microcortes, menos tickets y menos dependencia de reconexiones programadas para cambios que deberían ser rutinarios.
DNS: mejor soporte nativo y más herramientas para políticas modernas
Si hay un terreno donde las VPN sufren —por comportamiento inconsistente entre sistemas y por integración con el stack de red— es el DNS. OpenVPN 2.7 introduce mejor soporte del lado del cliente para opciones DNS, incorporando implementaciones para Linux, BSD y macOS en la instalación por defecto, y sumando una nueva implementación en Windows para habilitar funciones como split DNS y DNSSEC.
Para empresa, esto se traduce en algo muy concreto: más facilidad para aplicar políticas del tipo “los dominios internos por la VPN, el resto por el resolutor local”, sin depender tanto de soluciones ad hoc. También llegan dos nuevas variables de entorno para comunicar a plugins (como NetworkManager) la intención de redirección de gateway por defecto, un detalle relevante cuando el cliente se integra en escritorios Linux gestionados o entornos corporativos con perfiles de red controlados.
Windows cambia de marcha: win-dco por defecto y servicio con menos privilegios
El capítulo de Windows es, probablemente, el más sensible para despliegues masivos. OpenVPN 2.7 refuerza la arquitectura con medidas como la aplicación del flag block-local mediante filtros WFP (Windows Filtering Platform), la generación de adaptadores de red bajo demanda y la ejecución del servicio automático como usuario sin privilegios, un movimiento alineado con buenas prácticas de hardening.
Además, OpenVPN 2.7 incorpora soporte para modo servidor en el driver win-dco y fija un cambio que obligará a revisar procedimientos: se elimina el soporte del driver wintun; a partir de ahora, win-dco es el predeterminado y tap-windows6 queda como alternativa para los casos no cubiertos por win-dco. Es una decisión que apunta a consolidar una base de driver más uniforme, pero que puede requerir validación previa en entornos con dependencias específicas o automatizaciones antiguas.
Canal de datos: límites para AES-GCM y nuevas claves por época
En seguridad, OpenVPN 2.7 introduce mejoras en el canal de datos con la aplicación de límites de uso para AES-GCM y la incorporación de epoch data keys junto a un formato de paquetes revisado. Este tipo de cambios no suelen ser titulares de marketing, pero importan: refuerzan garantías criptográficas y acotan riesgos operativos en sesiones largas o con alto volumen de tráfico.
También se ajusta un mecanismo defensivo conocido como “Recursive Routing”, que ahora se vuelve más granular: solo descarta paquetes dentro del túnel cuando el destino IP, protocolo y puerto coinciden con los necesarios para llegar al servidor VPN, evitando bloqueos excesivos y reduciendo falsos positivos en configuraciones complejas.
Qué deberían revisar los equipos de IT antes de actualizar
OpenVPN 2.7 es una versión atractiva, pero conviene abordarla con mentalidad de producción. Un checklist sensato incluiría:
- Validar el impacto del cambio en Windows por la retirada de wintun y el nuevo rol de win-dco.
- Probar políticas DNS (split DNS/DNSSEC y comportamiento por sistema operativo), sobre todo en flotas mixtas.
- Planificar el uso de DCO en Linux si se busca rendimiento adicional, evaluando kernel, backports y compatibilidad.
- Aprovechar PUSH_UPDATE para reducir reconexiones y ajustar operación de cambios (rutas, DNS, políticas).
En conjunto, OpenVPN 2.7 se percibe menos como un “release incremental” y más como una versión que consolida una transición: más capacidades de kernel/offload, más dinamismo en configuración y un refuerzo serio del cliente Windows. Para quienes viven de mantener túneles estables —y no de reiniciar conexiones para resolver problemas—, ese enfoque es, probablemente, la noticia más importante.
Preguntas frecuentes
¿Qué ventajas aporta OpenVPN 2.7 con DCO en Linux para servidores con muchos usuarios?
DCO (Data Channel Offload) busca mejorar eficiencia del canal de datos al apoyarse en un módulo de kernel, lo que puede ayudar en escenarios de alta concurrencia o tráfico elevado.
¿Qué es PUSH_UPDATE en OpenVPN 2.7 y por qué interesa en entornos corporativos?
Permite enviar actualizaciones de opciones (rutas y DNS, entre otras) sin obligar al cliente a reconectar, reduciendo microcortes y mejorando la gestión de cambios.
¿Qué implica que se elimine wintun y win-dco sea el driver por defecto en Windows?
Implica revisar compatibilidades y procedimientos de despliegue: win-dco pasa a ser la opción estándar, mientras tap-windows6 queda como alternativa para casos no cubiertos por win-dco.
¿Qué mejoras introduce OpenVPN 2.7 para DNS en clientes y políticas tipo split DNS?
Añade implementaciones de DNS incluidas por defecto en Linux/BSD/macOS y una nueva implementación en Windows con soporte de split DNS y DNSSEC, facilitando políticas modernas de resolución.
