Más allá de la VPN: túneles y redes mesh para conectividad privada

Las VPN llevan décadas siendo el recurso por defecto para proteger conexiones remotas. Pero la proliferación del trabajo distribuido, los entornos multi-cloud y los dispositivos móviles ha puesto en evidencia sus limitaciones. Una «nueva» generación de herramientas (Cloudflare Tunnel, Tailscale, NetBird, ZeroTier, Yggdrasil) tratan de resolver algunos de los problemas que el modelo de VPN clásico nunca fue diseñado para afrontar.

Problemas del modelo VPN

Una VPN tradicional (WireGuard, OpenVPN, IPsec) funciona creando un túnel cifrado entre el cliente y un servidor central (gateway). Todo el tráfico pasa por ese punto: el servidor descifra, reenvía y cifra de vuelta. Es un modelo hub-and-spoke [arquitectura de red en la que todos los nodos periféricos (spokes) se conectan exclusivamente a través de un punto central (hub)] que funciona bien cuando hay pocos usuarios, una sede central y una red perimetral clara.

Los problemas aparecen en escenarios modernos:

• Latencia artificialmente alta: el tráfico hace un desvío innecesario por el gateway aunque origen y destino estén cerca.
• Servidor como punto único de fallo y cuello de botella: si cae, cae la conectividad.
• Gestión de claves y certificados: compleja y propensa a errores en equipos pequeños.
• Exposición de superficie: el servidor VPN «escucha» constantemente y por tanto es relativamente sencillo de ser escaneado (Shodan).
• Granularidad de acceso limitada por defecto: aunque el split tunneling es posible en la mayoría de clientes modernos, configurarlo con precisión por aplicación o por destino requiere intervención manual. En implementaciones corporativas típicas el comportamiento por defecto sigue siendo enrutar todo el tráfico por el túnel.

Lo que sí hacen bien:

• Cifrado robusto.
• Anonimización de IP.
• Cumplimiento normativo en algunos contextos.
• Amplia base de soporte en hardware y sistemas operativos.

Cloudflare Tunnel: exponer servicios sin abrir puertos

Cloudflare Tunnel (antes Argo Tunnel) invierte el modelo clásico. En lugar de que el servidor espere conexiones entrantes, es el servicio interno el que establece una conexión saliente persistente hacia la red de Cloudflare. El cliente accede al servicio a través de un dominio público, y Cloudflare actúa de intermediario.

Funcionamiento: el servicio cloudflared se instala en el servidor de origen (RBPi, NAS, PC…) y mantiene un túnel cifrado (QUIC/HTTP2) hacia los nodos de Cloudflare; no se abre ningún puerto en el firewall. El acceso puede protegerse con Cloudflare Access (autenticación Zero Trust). Todo el tráfico pasa por la infraestructura de Cloudflare, lo que implica dependencia del proveedor y visibilidad sobre el tráfico no cifrado de extremo a extremo; la IP del cliente tampoco queda anonimizada frente a Cloudflare. El plan gratuito cubre la mayoría de casos personales; los planes de pago añaden políticas avanzadas de acceso para equipos.

Dificultad de implementación: baja. Un binario, un comando, un dominio configurado.

Disponibilidad: Linux, Windows, MacOS, Docker. Administración vía dashboard web o CLI.

Cuándo usarlo frente a una VPN: Ideal para exponer aplicaciones web internas (Immich, Plex, Jellyfin, Nextcloud, paneles de administración) sin abrir puertos y con autenticación centralizada.

Tailscale: red mesh sin (casi) servidores

Tailscale construye una red privada peer-to-peer entre dispositivos usando WireGuard como protocolo de transporte. Cada nodo obtiene una IP fija en el rango 100.x.x.x y puede comunicarse directamente con cualquier otro nodo de la red (tailnet), sin tráfico centralizado cuando la conexión directa sea posible.

Funcionamiento: Tailscale usa un plano de control centralizado (servidores de coordinación propios) para distribuir las claves públicas WireGuard y gestionar la autenticación. El tráfico viaja directamente entre pares siempre que sea posible. Si nos encontramos bajo un NAT estricto o CGNat, Tailscale recurre a los servidores DERP: nodos de retransmisión distribuidos geográficamente que actúan como intermediarios. El tráfico viaja cifrado de extremo a extremo con WireGuard (los servidores DERP no pueden leerlo), pero sí introducen latencia adicional y dependencia de su infraestructura. El plano de control es propietario, aunque existe la opción de instalar Headscale (incompatible con los túneles de Cloudflare), una implementación open-source compatible que permite autohospedar dicho servidor de coordinación. Incluye MagicDNS (resolución de nombres entre nodos) y subnet routers (acceso a redes locales sin instalar el cliente en cada máquina), lo que lo hace especialmente útil en móviles y conexiones domésticas detrás de CGNAT.

Dificultad de implementación: muy baja. Instalación en minutos; la curva sube si se autohospeda mediante Headscale (no compatible con los túneles Cloudflare).

Disponibilidad: Linux, Windows, MacOS, iOS, Android, Raspberry Pi, Docker, FreeBSD, routers con OpenWrt.

Cuándo usarlo frente a una VPN: Para acceso remoto entre dispositivos propios , homelab, trabajo remoto con acceso a recursos locales. Eludir el CGNat. Puede reemplazar un servidor VPN habilitando «Nodo de salida» pero no a un cliente de pago (Proton, Mullvad, iVPN…)

NetBird: Zero Trust mesh con autohospedaje nativo

NetBird es conceptualmente similar a Tailscale (red mesh sobre WireGuard) pero con una diferencia filosófica importante: está diseñado desde el origen para ser completamente autohospedado y open-source. El plano de control (servidor de señalización y gestión) puede correr en infraestructura propia.

Funcionamiento: cada nodo NetBird establece conexiones P2P directas usando ICE/STUN/TURN; tres protocolos que trabajan en cadena para resolver el mismo problema: dos dispositivos detrás de routers distintos no pueden conectarse directamente porque ninguno tiene una IP pública accesible.

El servidor de gestión distribuye políticas de acceso por grupos y reglas granulares (qué nodo puede hablar con qué nodo y en qué puertos). Si bien dispone de ofertas para instalarlo en sus servidores, su propósito general es para ser auto-hospedado. Adecuado para entornos donde la propia gestión de los datos y el plano de control resulten prioritarios, cuenta con una comunidad activa y un desarrollo constante.

Dificultad de implementación: media. El cliente es sencillo; desplegar el servidor de gestión propio requiere Docker y algo de configuración.

Disponibilidad: Linux, Windows, macOS, Android, Docker, Kubernetes (operador disponible).

Cuándo usarlo frente a una VPN: Entornos corporativos o proyectos donde se requiera la versión de pago de Tailscale . Para la segmentación de accesos entre servicios y donde la normativa exiga un control total de la infraestructura de autenticación.

ZeroTier: Ethernet virtual a escala global

ZeroTier opera en una capa diferente a las demás herramientas de esta lista. Mientras Tailscale o NetBird crean redes IP enrutadas (N3), ZeroTier emula una red Ethernet (N2) de área local sobre internet: los nodos se comportan como si estuvieran conectados al mismo switch físico, con soporte para broadcast, multicast y cualquier protocolo que funcione sobre Ethernet.

Funcionamiento: ZeroTier combina un plano de control centralizado (ZeroTier Central o un controlador autohospedado) con un protocolo P2P propio para el tráfico de datos. Cada red tiene un identificador de 16 caracteres al que los nodos se unen. El controlador gestiona las políticas de acceso y distribuye certificados de red; el tráfico viaja directamente entre pares cuando es posible, con roots (servidores públicos operados por ZeroTier que actúan como directorio indicando a cada nodo dónde está el otro) pudiendo hacer la función de fallback [si la conexión directa no es posible (NAT estricto o CGNAT), el tráfico se retransmite a través de esos mismos servidores como último recurso]. El cifrado usa Curve25519 y AES-256-GCM.

Trabaja en capa 2 (Ethernet), no solo en capa 3 (IP). Esto permite casos de uso imposibles para otras herramientas: compartir impresoras en red, usar protocolos legacy que no hablan TCP/IP estándar, o conectar máquinas virtuales como si compartieran un mismo switch físico.

El plano de control en la nube es de ZeroTier Inc. pero también dispone de opción para autohospedar el controlador de red con ZeroTier Network Controller (código abierto), aunque la implementación es más compleja que en NetBird.

Soporta reglas de flujo (flow rules): políticas de red que permiten filtrar, redirigir o etiquetar tráfico a nivel de paquete dentro de la red virtual. La latencia suele ser algo mayor que en Tailscale/NetBird en conexiones directas, por la sobrecarga del modelo Ethernet.

Dificultad de implementación: baja con el plano de control en la nube; media si se autohospeda el controlador.

Disponibilidad: Linux, Windows, MacOS, iOS, Android, FreeBSD, Synology NAS, routers con OpenWrt, Docker. Una de las listas de plataformas más amplias del ecosistema.

Cuándo usarlo frente a una VPN: En la interconexión de entornos donde se necesita un comportamiento de red local completo (juegos LAN, protocolos de descubrimiento, dispositivos NAS, entornos industriales con protocolos propietarios sobre Ethernet); también como alternativa a VPN de sitio a sitio cuando los extremos son diversos y no comparten tecnología.

Yggdrasil: la red que se enruta sola

Yggdrasil es una propuesta diferente: no es un producto comercial sino un protocolo de red experimental que implementa un esquema de enrutamiento descentralizado basado en una topología de árbol de expansión (spanning tree). Cada nodo obtiene una IPv6 única derivada de su clave pública criptográfica.

Funcionamiento: los nodos se conectan entre sí formando una red superpuesta (overlay). El enrutamiento es automático y no requiere servidor central: los paquetes encuentran su camino usando el árbol de coordenadas de la red. El cifrado es extremo a extremo por diseño.

Es absolutamente descentralizado: no hay plano de control, no hay empresa detrás, no hay dependencia de terceros. La IP de cada nodo es permanente y obtenida criptográficamente, no cambia aunque el nodo se mueva entre redes.

La latencia puede ser impredecible, dependiendo de la topología de pares conocidos. No es una solución lista para producción empresarial; es más adecuada para proyectos de investigación, redes comunitarias o usuarios con perfil técnico elevado (bastante elevado).

Dificultad de implementación: Alta. Requiere entender el modelo de pares y la configuración manual de conexiones iniciales.

Disponibilidad: Linux, Windows, MacOS, Android (no oficial), iOS (limitado), routers.

Cuándo usarlo frente a una VPN: En escenarios donde la resiliencia ante censura o interrupción de infraestructura centralizada es prioritaria; redes comunitarias o mesh locales; investigación de protocolos descentralizados.

¿Cuándo sigue teniendo sentido una VPN clásica?

Las VPN tradicionales siguen siendo la opción correcta cuando:

• Se necesita anonimización de IP frente a proveedores de internet.
• Simplemente buscamos eludir la geolocalización de servicios.
• Cuando el entorno requiera compatibilidad con varios tipos de elementos de red (firewalls corporativos, routers con cliente IPsec embebido).
• Cuando las políticas de cumplimiento normativo exigen soluciones con certificaciones específicas.
• Y en general, para la inmensa mayoría de usuarios.

Para acceder remotamente a nuestros equipos o exponer de forma segura servicios que tengamos corriendo en nuestra red local; las alternativas descritas ofrecen una menor superficie de ataque, mejor usabilidad y, en varios casos, mayor control sobre toda la red.