Durante más de veinte años, la VPN ha sido la respuesta estándar a una pregunta esencial: ¿cómo permitir que usuarios y sedes remotas accedan de forma segura a la infraestructura corporativa? Pero el perímetro que la VPN fue diseñada para proteger se ha disuelto: aplicaciones repartidas entre el datacenter y la nube, empleados trabajando desde cualquier lugar y atacantes que han aprendido a explotar el punto débil del modelo: una vez dentro del túnel, la red entera queda al alcance.
Frente a este escenario ha ganado terreno el ZTNA (Zero Trust Network Access), un modelo que sustituye el acceso a la red por el acceso a la aplicación, con verificación continua de la identidad del usuario y de la postura del dispositivo. ¿Significa eso que la VPN está muerta? En absoluto: los túneles site-to-site entre oficinas y datacenter, el acceso a redes de gestión o los protocolos no web siguen siendo su territorio natural.
En este artículo comparamos ambas tecnologías desde el punto de vista técnico: cómo funcionan, dónde falla cada una y cómo combinarlas en un enfoque híbrido realista. Si lo que buscas es el modelo estratégico completo de Zero Trust —principios, fases de adopción y arquitectura de referencia—, lo tratamos en nuestra guía práctica de Zero Trust; aquí nos centramos en la comparativa tecnológica del acceso remoto.
Cómo Funciona una VPN: Túneles Cifrados con IPsec, WireGuard y OpenVPN
Una VPN crea un túnel cifrado entre dos extremos: el tráfico IP se encapsula, se cifra y viaja por internet como si ambos extremos estuvieran conectados al mismo cable. Para el sistema operativo, la red remota aparece como una interfaz de red más, con su rango de direcciones y sus rutas. Los tres protocolos dominantes hoy son IPsec, OpenVPN y WireGuard.
IPsec es el estándar del IETF y opera a nivel de red, con IKEv2 para la negociación de claves. Es el protocolo por defecto en firewalls y routers empresariales, y por eso domina los túneles site-to-site: interoperabilidad probada entre fabricantes, aceleración hardware y dos décadas de madurez. Su contrapartida es una configuración compleja, con muchos parámetros que deben coincidir en ambos extremos.
OpenVPN se apoya en TLS y funciona en espacio de usuario, lo que lo hace extremadamente portable y capaz de atravesar redes restrictivas encapsulando el tráfico en TCP/443. A cambio, su rendimiento es el más bajo de los tres. WireGuard es el recién llegado que ha cambiado las reglas: unas 4.000 líneas de código (frente a cientos de miles de OpenVPN o las pilas IPsec), criptografía moderna sin negociación (ChaCha20-Poly1305, Curve25519), integración en el kernel de Linux desde la versión 5.6 y un rendimiento muy superior con una configuración mínima basada en pares de claves, al estilo SSH.
VPN de Acceso Remoto vs VPN Site-to-Site
Bajo la palabra "VPN" conviven dos casos de uso muy distintos que a menudo se confunden. La VPN de acceso remoto conecta a un usuario individual con la red corporativa: un cliente instalado en el portátil levanta el túnel contra un concentrador situado en el perímetro, y a partir de ahí el empleado trabaja "como si estuviera en la oficina". Es el modelo del teletrabajo clásico y el que ZTNA pone en cuestión.
La VPN site-to-site conecta redes completas entre sí: el firewall de la sede establece un túnel permanente —casi siempre IPsec— contra el firewall del datacenter, y los equipos de ambas redes se comunican de forma transparente, sin clientes ni intervención del usuario. Es la solución natural para unir la oficina con la infraestructura alojada: los servidores del datacenter aparecen como una subred más de la empresa. Este tipo de interconexión es parte habitual de nuestras soluciones de red para clientes con servidores dedicados y cloud privado.
Esta distinción importa porque el debate VPN vs ZTNA afecta casi exclusivamente al primer caso. ZTNA compite con el acceso remoto de usuarios; los túneles site-to-site entre infraestructuras resuelven un problema diferente para el que ZTNA no está diseñado.
Las Limitaciones del Modelo VPN de Acceso Remoto
El problema estructural de la VPN de acceso remoto es su modelo de confianza: autentica una vez y concede acceso a la red, no a aplicaciones concretas. Salvo que exista una segmentación interna cuidadosa, el usuario que supera la autenticación aterriza en una red plana donde puede alcanzar servidores, bases de datos y servicios que no necesita para su trabajo.
Esa amplitud es exactamente lo que un atacante necesita para el movimiento lateral: comprometido un equipo o unas credenciales, el túnel VPN se convierte en una autopista hacia el resto de la infraestructura. Unas credenciales robadas mediante phishing equivalen a la red entera si no hay MFA, y las campañas de ransomware llevan años explotando precisamente esta vía de entrada. La segmentación interna mitiga el daño —lo explicamos en detalle en nuestro artículo sobre VLANs y microsegmentación de red—, pero no elimina el problema de origen.
El segundo frente es el propio concentrador VPN. Por un lado es un cuello de botella: todo el tráfico remoto pasa por él, incluso el destinado a aplicaciones SaaS, con la latencia y el dimensionamiento que eso implica. Por otro, es un servicio expuesto a internet por definición, y los últimos años han dejado una lista larga de CVEs críticas en appliances VPN de fabricantes de primer nivel, explotadas de forma masiva antes de que existiera parche. Cada appliance VPN público es superficie de ataque permanente.
El problema de fondo:
La VPN de acceso remoto autentica una vez y confía para siempre durante la sesión. Sin controles adicionales, unas credenciales robadas equivalen a un cable de red conectado directamente dentro de tu datacenter.
Qué es ZTNA: Acceso por Aplicación con Verificación Continua
ZTNA (Zero Trust Network Access) invierte el modelo: en lugar de conectar al usuario a la red, un broker de acceso media cada conexión hacia cada aplicación individual. El usuario nunca "entra en la red"; solicita acceso a una aplicación concreta y el broker decide si lo concede, en función de políticas que evalúan mucho más que una contraseña.
Esa evaluación combina identidad y postura del dispositivo, y es continua: quién es el usuario (federado con el proveedor de identidad, con MFA), desde qué equipo se conecta (¿está cifrado el disco?, ¿tiene el EDR activo?, ¿está parcheado?), desde dónde y a qué hora. Si la postura cambia a mitad de sesión —el antivirus se desactiva, el dispositivo deja de cumplir la política—, el acceso se revoca sin esperar a la siguiente autenticación.
La diferencia arquitectónica clave es que las aplicaciones dejan de exponerse a internet: un conector ligero junto a la aplicación establece conexiones salientes hacia el broker, de modo que no hay ningún puerto público que escanear ni appliance que explotar. Y el principio rector es el mínimo privilegio por defecto: todo está denegado salvo lo que una política concede explícitamente, aplicación por aplicación y usuario por usuario. Cloudflare ofrece una buena introducción técnica a ZTNA como referencia neutral. Estos controles de acceso complementan —no sustituyen— las medidas de protección perimetral e interna que agrupamos en nuestros servicios de seguridad gestionada.
Tabla Comparativa: VPN vs ZTNA
La siguiente tabla resume las diferencias entre la VPN de acceso remoto y ZTNA en los criterios que más pesan al diseñar el acceso remoto de una organización:
| Criterio | VPN de acceso remoto | ZTNA |
|---|---|---|
| Modelo de confianza | Autenticación única; confianza durante toda la sesión | Verificación continua de identidad y postura |
| Granularidad | Red o subred completa | Aplicación individual |
| Superficie expuesta | Concentrador público en internet (CVEs) | Aplicaciones no expuestas; solo el broker |
| Experiencia de usuario | Cliente VPN; latencia por backhauling del tráfico | Transparente; acceso directo por aplicación |
| Complejidad | Baja-media (tecnología madura) | Media-alta (identidad + postura + políticas) |
| Coste | Bajo (appliance o software libre) | Suscripción por usuario/mes |
| Protocolos soportados | Cualquier tráfico IP | Principalmente web; protocolos legacy con limitaciones |
La lectura honesta de la tabla es que ZTNA gana en seguridad y granularidad, mientras que la VPN gana en simplicidad, coste y universalidad de protocolos. Por eso la respuesta correcta rara vez es "una u otra".
Cuándo la VPN Sigue Siendo la Respuesta Correcta
Pese al empuje comercial de ZTNA, hay escenarios donde la VPN no solo sigue vigente, sino que es la opción técnica superior:
- check_circle Túneles site-to-site entre oficina y datacenter: conectar redes completas de forma permanente es un problema de infraestructura, no de acceso de usuarios. Un túnel IPsec entre firewalls sigue siendo la solución estándar y la más eficiente.
- check_circle Acceso a redes de gestión (iLO, iDRAC, IPMI): las interfaces de gestión fuera de banda nunca deben exponerse a internet ni pasar por brokers de terceros. Una VPN dedicada hacia la red de gestión, con acceso restringido a administradores, es la práctica recomendada.
- check_circle Protocolos no web: replicación de bases de datos, SMB, tráfico de backup, aplicaciones cliente-servidor legacy o cualquier protocolo que necesite conectividad IP bidireccional funciona de forma natural sobre VPN y de forma forzada (o imposible) sobre muchos ZTNA.
- check_circle Presupuesto limitado: un servidor WireGuard bien gestionado —con MFA en la capa de identidad, claves por dispositivo, segmentación por rutas y revisión periódica de accesos— ofrece un nivel de seguridad excelente sin coste de licencias. Para un equipo pequeño, es difícil de batir.
Enfoque Híbrido: Migración Gradual sin Rupturas
En la práctica, la transición de VPN a ZTNA no es un reemplazo, sino una convivencia planificada. El camino que mejor funciona empieza por inventariar qué aplicaciones consumen los usuarios remotos y clasificarlas: las aplicaciones web internas y los servicios más sensibles son los primeros candidatos a pasar detrás del broker ZTNA, porque son donde la granularidad y la no exposición aportan más.
A medida que las aplicaciones migran, el concentrador VPN pierde tráfico y usuarios: puede reducirse su dimensionamiento, endurecerse sus políticas y limitarse su uso a los casos donde sigue siendo la herramienta adecuada —administradores accediendo a la red de gestión, protocolos legacy, túneles site-to-site—. El resultado final no es "cero VPN", sino una VPN pequeña, vigilada y con un propósito concreto, junto a un ZTNA que concentra el acceso del grueso de los usuarios.
Esta convivencia puede durar años sin ser un problema, siempre que cada tecnología tenga su ámbito bien delimitado y ambas se integren con el mismo proveedor de identidad y las mismas políticas de MFA.
Preguntas Frecuentes
¿ZTNA sustituye por completo a la VPN?
No. ZTNA sustituye con ventaja el acceso remoto de usuarios a aplicaciones, pero los túneles site-to-site entre sedes y datacenter, el acceso a redes de gestión (iLO, iDRAC) y los protocolos no web siguen siendo territorio natural de la VPN. La mayoría de organizaciones opera un modelo híbrido durante años.
¿Qué protocolo VPN es más recomendable: IPsec, WireGuard u OpenVPN?
Depende del caso de uso. IPsec es el estándar para túneles site-to-site entre firewalls por su interoperabilidad. WireGuard ofrece el mejor rendimiento con una base de código mínima y es ideal para acceso remoto moderno. OpenVPN destaca por madurez y compatibilidad cuando WireGuard no está disponible o el tráfico debe atravesar redes muy restrictivas.
¿Es ZTNA más caro que una VPN?
En licencias, normalmente sí: ZTNA suele facturarse por usuario y mes, mientras que una VPN autogestionada solo requiere un appliance o un servidor WireGuard. Para equipos pequeños, una VPN bien gestionada con MFA y segmentación es más económica. A partir de cierta escala, el coste operativo y el riesgo del modelo VPN pueden superar el coste de la suscripción ZTNA.
Conclusión
VPN y ZTNA no son competidores directos en todos los frentes: son herramientas con modelos de confianza distintos que resuelven problemas parcialmente solapados. Las ideas clave:
- arrow_right La VPN de acceso remoto concede acceso a la red tras una autenticación única: red plana, movimiento lateral posible y concentradores expuestos como superficie de ataque.
- arrow_right ZTNA concede acceso por aplicación con verificación continua de identidad y postura, sin exponer las aplicaciones a internet y con mínimo privilegio por defecto.
- arrow_right La VPN sigue siendo la respuesta correcta para túneles site-to-site, redes de gestión, protocolos no web y presupuestos ajustados con WireGuard bien operado.
- arrow_right El enfoque híbrido —ZTNA para el acceso de usuarios, VPN acotada para infraestructura y gestión— es el destino realista de la mayoría de organizaciones.
Si estás diseñando el acceso remoto a tu infraestructura alojada —túneles site-to-site, redes de gestión aisladas o una estrategia de migración hacia Zero Trust—, contacta con nuestro equipo para un análisis técnico sin compromiso.