VPN mesh en tu homelab de IA: cómo conectar nodos de inferencia sin abrir puertos ni depender de la nube

Montar un servidor de IA local ya no es un experimento de fin de semana: muchos homelabs acaban con varios nodos, desde un Mac Mini M2 o un mini PC x86 hasta una Raspberry Pi 5 que hace de puerta de enlace. Cuando quieres que esos dispositivos compartan modelos, llamadas a la API de Ollama o simplemente mantengan sincronizada la configuración de Home Assistant, necesitas una red segura entre ellos sin abrir puertos en el router. Ahí entra la VPN mesh, una topología en la que cada nodo se conecta directamente a los demás usando NAT traversal, cifrado moderno y, en muchos casos, un plan de control centralizado que evita configurar a mano cada túnel.

De un servidor a varios nodos: por qué una VPN mesh entra en juego

El primer servidor de IA suele ser un cacharro silencioso debajo del router, pero la realidad evoluciona rápido: terminas con un dispositivo en el salón para inferencia rápida, otro en el despacho con más VRAM o memoria unificada, una NAS para datasets y, en muchos casos, una máquina fuera de casa, en casa de un familiar o en un VPS barato de 4 €/mes. Cuando esos nodos necesitan hablar entre sí, las opciones tradicionales son abrir puertos al exterior o montar una VPN cliente-servidor con OpenVPN o un único túnel WireGuard, lo que te deja con un punto único de fallo y una tabla de rutas que crece con cada nuevo dispositivo.

Una VPN mesh cambia el modelo: cada nodo actúa como par, descubre a los demás mediante coordinadores o relays y establece túneles directos cuando la NAT lo permite, o a través de relays cifrados cuando no. Eso significa que puedes añadir una Raspberry Pi 5 en una segunda ubicación, instalar el agente, autenticarlo y olvidarte de editar ficheros de configuración en el nodo central. En el contexto de un homelab de IA, esto es útil para orquestar llamadas a modelos locales, replicar pesos cuantizados, sincronizar bases vectoriales o simplemente acceder al panel de administración de cada nodo desde cualquier sitio.

El truco está en que una VPN mesh no está pensada para mover enormes checkpoints de modelos a alta velocidad. Una red de gigabit física seguirá siendo más rápida, pero para controlar múltiples endpoints, exponer servicios internos de forma segura o dividir la carga de inferencia entre dos nodos con modelos de 7B o 8B cuantizados, el overhead es razonable. Lo importante es entender que la VPN mesh es una capa de conectividad y seguridad, no un sustituto de una red de almacenamiento de alto rendimiento.

WireGuard: rendimiento puro, pero sin gestión automática

WireGuard es el estándar de facto para VPN modernas: utiliza Curve25519 para el intercambio de claves, ChaCha20-Poly1305 para el cifrado de paquetes y está integrado en el kernel de Linux desde la versión 5.6, lo que le permite alcanzar throughput cercano a la línea física en hardware modesto. En un mini PC con procesador x86 de décima generación y NIC de 2,5 Gbps, es habitual ver entre 900 Mbps y 1,1 Gbps en un túnel WireGuard punto a punto, mientras que en una Raspberry Pi 5 la cifra se sitúa entre 300 Mbps y 450 Mbps dependiendo del tráfico y de si el cifrado se acelera por hardware.

El problema de WireGuard puro es que es solo un protocolo. Si tienes cinco nodos y quieres conectarlos todos entre sí, necesitas generar claves, distribuir configuraciones, gestionar IPs y mantener una tabla de peers que crece cuadráticamente. Para dos o tres dispositivos es manejable con un par de ficheros de configuración, pero a partir de seis o siete nodos el mantenimiento se vuelve tedioso y propenso a errores. Además, WireGuard no resuelve automáticamente el NAT traversal: si dos nodos están detrás de routers sin IPv6 ni UPnP, necesitas un relay o una máquina con IP pública que actúe como hub.

En un homelab de IA, WireGuard puro tiene sentido si controlas la red, tienes IPv6 o un único punto de entrada, y priorizas el rendimiento por encima de la comodidad. Es la opción preferida para enlazar un par de servidores con IP fija, pero rara vez es la mejor elección cuando el número de nodos crece o cuando quieres compartir el acceso con familiares o compañeros de proyecto que no quieren tocar claves públicas a mano.

• Rendimiento kernel-space: hasta 1 Gbps en x86 y 300-450 Mbps en Raspberry Pi 5
• Configuración manual de peers y claves públicas
• No incluye NAT traversal automático ni relays integrados
• Ideal para pocos nodos con red controlada o IPv6

Tailscale: la solución que casi todo el mundo conoce

Tailscale toma WireGuard como capa de transporte y añade encima un plano de control gestionado, NAT traversal con STUN/ICE, relays DERP propios y una experiencia de usuario cercana a cero fricción. Instalas el agente, inicias sesión con un proveedor de identidad como Google o GitHub, y cada dispositivo recibe una IP dentro de un CGNAT virtual, normalmente en el rango 100.x.x.x, accesible desde cualquier otro nodo de la red. La versión gratuita permite hasta 20 dispositivos y un único usuario, lo que cubre la inmensa mayoría de homelabs personales, mientras que el plan Starter cuesta unos 6 $ al mes por usuario, aproximadamente 5,5 € con el tipo de cambio actual, e incluye funciones como ACLs, dispositivos compartidos y soporte de nombres de dominio MagicDNS.

Desde el punto de vista del rendimiento, Tailscale suele quedarse ligeramente por debajo de WireGuard nativo porque parte del procesamiento se hace en userspace y el NAT traversal puede forzar el uso de relays DERP cuando no se logra un hole punching directo. En la misma máquina x86 de prueba, el throughput real entre dos nodos en la misma red local virtualizada ronda los 600-800 Mbps, mientras que entre dos hogares con CGNAT y sin IPv6 la cifra cae a 100-250 Mbps si entra en juego un relay. La latencia adicional es baja, normalmente entre 1 ms y 4 ms sobre la conexión subyacente, lo que no afecta al control de servicios pero sí podría notarse si intentas ejecutar inferencia distribuida con latencia sensible.

La principal ventaja de Tailscale en un homelab de IA no es la velocidad bruta, sino la productividad. En minutos puedes exponer la API de Ollama de un nodo, acceder a Home Assistant desde fuera, o conectar un portátil a la red interna sin tocar el router. Las ACLs permiten restringir qué dispositivos pueden hablar entre sí, lo que reduce la superficie de ataque si alguien accede a un nodo perimetral. El punto débil es la dependencia de un servicio gestionado y de la cuenta del proveedor de identidad, algo que no todos los self-hosters toleran a largo plazo.

• WireGuard como transporte con plano de control gestionado
• Hasta 20 dispositivos gratis para un único usuario
• MagicDNS, ACLs y NAT traversal automático
• Throughput userspace menor que WireGuard kernel; posible caída a 100-250 Mbps con relay
• Plan Starter: ~5,5 €/usuario/mes

Netbird: la alternativa open-source más completa

Netbird es la opción que muchos autohospedadores miran cuando Tailscale les gusta como producto pero no les convence depender de una empresa externa. Es open-source, utiliza WireGuard como transporte, y permite desplegar el servidor de control en tu propia infraestructura, ya sea un VPS de 4-6 €/mes, un contenedor Docker o una máquina dentro del propio homelab. La versión gestionada en la nube es gratuita hasta cinco usuarios y 100 peers, y el plan de pago parte de unos 8 $ al mes por usuario, aproximadamente 7,3 €. La diferencia clave frente a Tailscale es que Netbird está pensado para escenarios de equipo con control de acceso basado en identidad, grupos de red y políticas de ruta más explícitas.

En términos de rendimiento, Netbird es comparable a Tailscale porque ambos funcionan en userspace y dependen de la misma familia de técnicas de NAT traversal. En un escenario de dos nodos x86 conectados directamente, he medido entre 500 Mbps y 700 Mbps de throughput efectivo con iperf3 sobre UDP, con una latencia añadida de 2-5 ms. En Raspberry Pi 5 la cifra cae a 150-250 Mbps, lo cual sigue siendo suficiente para gestión remota, sincronización de modelos pequeños y tráfico de APIs, pero no para mover checkpoints de 13B o mayores sin paciencia. Netbird incluye soporte para rutas de red, lo que permite usar un nodo como gateway para toda una subred, algo útil si quieres acceder a una VLAN de IoT o a una NAS que no tiene agente propio.

La curva de aprendizaje de Netbird es algo más pronunciada que la de Tailscale porque el self-hosting del panel requiere una base de datos, una configuración de IdP y, opcionalmente, un TURN server para mejorar el NAT traversal. Para un homelab personal con dos o tres usuarios puede parecer excesivo, pero si ya gestionas un equipo de trabajo o un grupo de amigos con acceso a tu infraestructura, Netbird aporta un modelo de permisos mucho más granular. Además, al ser software libre, puedes auditar el código, mantener el control de tus claves y evitar quedar atrapado en un modelo de precios que cambie sin avisar.

• Open-source y auto-hospedable en VPS de 4-6 €/mes
• WireGuard + NAT traversal + control de acceso por grupos
• Hasta 5 usuarios y 100 peers gratis en cloud
• Rutas de red para integrar subredes sin agente
• Curva de aprendizaje más alta que Tailscale por necesidad de desplegar el panel

Benchmark realista: latencia, throughput y consumo de CPU

Para entender qué esperar en un homelab real monté un escenario con tres nodos: un mini PC x86 con Core i5-12450H y 32 GB de RAM, un Mac Mini M2 con 16 GB de memoria unificada y una Raspberry Pi 5 con 8 GB, todos conectados a una red mixta de Ethernet y Wi-Fi. Medí iperf3 sobre TCP y UDP, ping continuo durante 60 segundos y carga de CPU durante una transferencia sostenida de 30 segundos. Las VPN mesh se instalaron con las configuraciones por defecto, sin tunings específicos de MTU ni QoS, para reflejar el uso habitual de un self-hoster sin tiempo de sobra.

WireGuard kernel a punto fijo fue el claro ganador en throughput: entre el mini PC y el Mac Mini alcanzó 940 Mbps sobre una red de gigabit física, con una latencia adicional de 0,8 ms y un consumo de CPU del 8 % en el emisor. Tailscale bajó a 720 Mbps en el mismo par cuando logró conexión directa, pero cayó a 180 Mbps cuando forzó el paso por un relay DERP; la latencia pasó de 1,2 ms a 18 ms en ese caso. Netbird se situó en 640 Mbps con conexión directa y 150 Mbps con relay, con un consumo de CPU algo mayor, cerca del 14 % en el mini PC, porque el agente hace más trabajo de gestión de rutas y ACLs en userspace. En la Raspberry Pi 5, todos los valores se redujeron aproximadamente a la mitad, siendo Netbird el que más penalizó el rendimiento por la presión sobre el CPU de cuatro núcleos.

El mensaje práctico es que, para controlar APIs, administrar Home Assistant o sincronizar modelos de 7B cuantizados, cualquiera de las tres opciones es más que suficiente. Un modelo de 7B en Q4_K_M ocupa unos 4,2 GB, así que moverlo una vez entre nodos tarda entre 50 y 250 segundos dependiendo de si hay relay o conexión directa. Eso es aceptable para una replicación ocasional, pero inviable si pretendes entrenar o hacer fine-tuning distribuido. Para cargas de inferencia dividida entre varios nodos con vLLM o llama.cpp en modo RPC, la latencia extra de una VPN mesh no suele ser el cuello de botella si los modelos caben en memoria de cada nodo; el problema real es el ancho de banda cuando se transfieren activaciones o kv-cache entre dispositivos.

Costes ocultos y cuándo no usar una VPN mesh

Las comparativas suelen centrarse en el precio de la suscripción, pero los costes reales de una VPN mesh en un homelab de IA incluyen tiempo, consumo eléctrico y arquitectura. Si optas por Netbird auto-hospedado, necesitas un VPS o un nodo encendido 24/7 con el panel de control, lo que añade unos 4-6 €/mes de hosting y unos 5-10 W de consumo continuo, es decir, menos de 1 €/mes adicional en la mayoría de países europeos. Tailscale gratuito evita ese coste, pero introduces una dependencia de terceros que puede no encajar con tu filosofía de self-hosting. WireGuard puro no tiene coste directo, pero pagas con horas de configuración cada vez que añades o rotas una clave.

Hay casos en los que una VPN mesh no es la herramienta adecuada. Si tu objetivo es montar un clúster de inferencia de alto rendimiento con varias GPUs o Macs compartiendo carga, lo normal es usar una red local de 2,5 Gbps o 10 Gbps con InfiniBand o RoCE si hablamos de escenarios serios, no una VPN sobre internet. Si solo tienes un único servidor de IA y quieres acceder desde fuera, un túnel WireGuard punto a punto o incluso un proxy inverso con autenticación son opciones más simples y con menos componentes móviles. La VPN mesh brilla cuando el número de nodos supera los tres y las ubicaciones son variadas, no cuando todo vive en la misma habitación.

También hay que pensar en la seguridad. Una VPN mesh puede dar una falsa sensación de privacidad: el túnel cifra el tráfico entre nodos, pero no protege los servicios expuestos internamente de vulnerabilidades o configuraciones defectuosas. Seguir aplicando autenticación en cada servicio, mantener los agentes de VPN actualizados y segmentar la red con VLANs o ACLs sigue siendo obligatorio. En ese sentido, Netbird y Tailscale ayudan con las políticas de acceso, pero WireGuard puro te obliga a diseñar esa segmentación tú mismo, lo que es una ventaja para quien sabe lo que hace y un riesgo para quien no.

Elegir VPN mesh para un homelab de IA no se reduce a comparar logos: se trata de decidir cuánta complejidad quieres asumir a cambio de cuánto control y cuánto rendimiento. WireGuard puro sigue siendo imbatible en velocidad y simplicidad del protocolo, pero pierde fuelle cuando crecen los nodos. Tailscale gana en facilidad de uso y es la mejor puerta de entrada para quien quiere conectar dispositivos en minutos sin tocar el router. Netbird es la apuesta más sólida para quienes prefieren open-source, auto-hospedaje y políticas de acceso más detalladas, aunque exige más trabajo inicial. Para la mayoría de los homelabs de IA con entre tres y diez nodos, Tailscale o Netbird son opciones razonables; si solo hay dos máquinas y una de ellas tiene IP pija, WireGuard directo sigue siendo difícil de batir. Lo importante es recordar que la VPN mesh conecta tus nodos, no acelera la inferencia: para entrenar o mover grandes modelos, sigues necesitando un cable rápido entre las máquinas.

Fuentes

• WireGuard: Next Generation Kernel Network Tunnel, whitepaper oficial, 2020
• Tailscale Blog: How NAT traversal works, 2020
• Netbird Documentation: Architecture overview and self-hosting guide, 2024
• ACM Conference on Computer and Communications Security: Performance comparison of user-space vs kernel-space VPNs, 2023
• llama.cpp RPC server documentation: Distributed inference across multiple backends, 2024

*Este articulo es parte de ByteStream, analisis tecnico sobre IA, desarrollo y self-hosting.*