WireGuard resolvio en 2019 un problema real con las VPN: los protocolos existentes (OpenVPN, IPsec) funcionaban pero tenian configuración complicada, rendimiento mediocre y superficie de ataque grande. WireGuard llego con menos de 4.000 lineas de código, una criptografia moderna y un modelo tan simple que cabe en dos páginas de documentación. Para un enlace punto a punto entre dos nodos, montar WireGuard es cuestion de media hora. Para una malla de cinco, diez o veinte nodos comunicandose entre ellos, la cosa se complica rapido y aparecen patrones repetidos, ciertas formas de fallo y decisiones que conviene entender antes de empezar. Repaso lo que he aprendido montando mallas WireGuard en varios entornos, cuando el patron manual sigue siendo razonable, y cuando conviene subir al nivel siguiente con Tailscale o Headscale.
Por que una malla no es solo repetir enlaces
El modelo mental de WireGuard es simple: cada nodo es un peer con una clave publica y una clave privada, y tiene una lista de otros peers con sus claves y sus rangos de IP permitidos. Para dos nodos, esto es trivial. Para diez nodos, cada uno debe conocer los otros nueve, lo que significa que cada vez que anades o quitas un nodo tienes que actualizar la configuración en todos los demas. El coste no es técnico, es organizativo: olvidarse de un nodo al retirar uno antiguo deja una puerta abierta que nadie esta vigilando.
La segunda complicacion es el enrutado. Si los nodos estan en redes distintas, cada uno necesita saber que subredes le llegan por que peer. Cuando además quieres que cualquier nodo pueda hablar con servicios detras de cualquier otro, como servicios internos en redes privadas, la configuración de allowed-ips se vuelve una cuestion delicada: una linea mal puesta y los paquetes se enrutan por el peer equivocado, el tráfico cae y te pasas una tarde haciendo tcpdump en tres sitios a la vez.
La tercera complicacion es NAT. Si todos los nodos estan en servidores con IP publica estable, todo funciona. En cuanto alguno esta detras de NAT (un portatil, un servidor en un domicilio, un dispositivo movil), los otros nodos no pueden iniciar conexión hacia el. Hay soluciones: mantener el tunel activo con persistent-keepalive, usar un nodo publico como rendezvous, o usar servicios externos de hole-punching. Ninguna es mala pero cada una anade configuración que hay que entender.
Patrones que funcionan para pocos nodos
Si la malla tiene entre dos y cinco nodos y todos tienen IP publica estable, el patron manual es razonable y funciona bien. Una convencion clara de claves, un repositorio git privado con los ficheros wg0.conf generados por una plantilla, y revisiones cruzadas cuando cambia algo. En este tamanio la malla se mantiene sola y los errores se detectan rapido porque cualquier fallo afecta inmediatamente a todo el sistema.
El patron que uso en estos casos tiene tres piezas. Primero, un esquema de direcciones claro: 10.10.0.0/24, con los nodos numerados 10.10.0.1, 10.10.0.2, etc. Nada de subredes anidadas ni mapeos indirectos; la dirección privada del nodo es su identidad. Segundo, una plantilla Jinja que genera el wg0.conf con los peers a partir de una lista central. Tercero, una revision manual cuando cambia algo: dos personas leen el diff antes de aplicarlo.
Este patron escala mal pero vive muy bien en rangos pequenios. Un equipo de cuatro personas con cinco servidores opera asi sin esfuerzo durante anios. Si alguien se incorpora al equipo, en una manana aprende como funciona. Si el equipo se descoordina, se nota rapido porque la malla empieza a comportarse mal.
En el fichero wg0.conf de cada nodo tipicamente se ve [Interface] PrivateKey = <clave privada> Address = 10.10.0.1/24 ListenPort = 51820 [Peer] PublicKey = <clave publica peer> AllowedIPs = 10.10.0.2/32 Endpoint = peer.example:51820 PersistentKeepalive = 25, y una sección Peer adicional por cada nodo vecino.
Donde el patron manual se rompe
El patron manual se rompe con claridad cuando la malla pasa de diez nodos o cuando los nodos se anaden y quitan con frecuencia. En una malla con doce servidores y tres portatiles, la administración manual se convierte en trabajo semanal y los errores humanos aparecen: un nodo retirado hace tres meses sigue listado en cinco configuraciones olvidadas, un portatil nuevo tarda medio dia en anadirse porque hay que coordinar cinco cambios.
También se rompe cuando la malla involucra maquinas que no puedes tratar como servidores estables (portatiles con usuarios diferentes, moviles con cambio de red, dispositivos IoT) y cuando las politicas de acceso son granulares. WireGuard puro no tiene concepto de grupos de peers ni reglas por aplicacion: si necesitas que el peer A hable con el peer B solo por el puerto 443 tienes que anadir reglas iptables en cada nodo, duplicando la carga de mantener dos conjuntos de configuración en sincronia.
Cuando subir a Tailscale
Tailscale resuelve la mayoria de estos problemas con un plano de control centralizado que gestiona claves, IPs y politicas, mientras el plano de datos sigue siendo WireGuard puro. Con Tailscale, anadir un nodo es instalar un agente y autenticarse. Los cambios en la malla se propagan solos en segundos. Las politicas de acceso se declaran en un fichero central y se distribuyen a todos los nodos.
La pega de Tailscale es que el plano de control vive en sus servidores. Para muchos equipos esto no es problema: Tailscale no ve el tráfico, solo coordina, y para cargas no regulados esto basta. Para equipos con requisitos de soberania o industrias con cumplimiento estricto, depender de un proveedor externo para la coordinacion de VPN es un no automático. Aqui entra Headscale.
Headscale es una reimplementacion de código libre del plano de control de Tailscale. Los nodos siguen usando el cliente oficial de Tailscale, pero el servidor de coordinacion lo controlas tu. Esto da lo mejor de ambos mundos: la comodidad de Tailscale, sin dejar fuera de tu infraestructura ni las claves ni las politicas. Pague el coste de mantener tu propio plano de control, que no es trivial pero es asumible.
Como elegir entre los tres
La decision entre WireGuard puro, Tailscale y Headscale se puede resumir en pocas preguntas. La primera es cuantos nodos tienes y con que frecuencia cambian. Si son pocos y estables, WireGuard puro sobra. Si son muchos o cambian a menudo, conviene una capa de control.
La segunda pregunta es quien opera. Si hay un equipo de sistemas dedicado con experiencia en redes, WireGuard puro o Headscale son opciones viables. Si el equipo es pequenio o no especializado, Tailscale elimina casi toda la carga operativa a cambio de dependencia externa.
La tercera pregunta es sobre regulacion. Si la empresa opera en sectores con requisitos de soberania de datos, Headscale o WireGuard puro son obligatorios. Si no hay esta restriccion, Tailscale suele ser la opcion mas comoda y la que menos tiempo come.
La cuarta es el tipo de tráfico. Si la malla es para acceso remoto de personas (portatiles y moviles), Tailscale brilla: MagicDNS, SSH integrado, ACL granulares. Si la malla es entre servidores estables para replicacion o sincronizacion de datos, WireGuard puro es igualmente valido y no anade latencia por coordinacion.
Los errores comunes que he visto
Hay errores que se repiten cuando un equipo monta una malla WireGuard por primera vez. El primero es confiar en que persistent-keepalive resuelva cualquier problema de NAT; si el NAT es simetrico los paquetes entrantes se bloquean y necesitas un nodo publico como rendezvous. El segundo es configurar allowed-ips como 0.0.0.0/0 en todos los peers: cada nodo se convierte en puerta por defecto para los demas y aparecen bucles de enrutado sorprendentes. Los rangos en allowed-ips deben ser minimos.
El tercero es olvidar que wg-quick reinicia la interfaz al aplicar cambios y eso mata conexiones activas; conviene coordinar estos reloads. El cuarto es no monitorizar la malla: un tunel caido no grita, simplemente deja de pasar tráfico y nadie se entera hasta que alguien intenta usarlo. Anadir checks básicos (ping entre nodos, métricas de bytes) a Prometheus ahorra muchas horas de depuracion a ciegas.
Como pensar la decision
Mi consejo si no sabes por donde empezar es montar una malla minima con WireGuard puro entre dos o tres servidores de prueba. En una tarde entiendes el modelo, ves como se comportan las claves, las IPs y el enrutado. Con ese entendimiento básico ya puedes decidir si el patron manual te vale o si necesitas una capa de control.
Si decides que necesitas capa de control, la eleccion entre Tailscale y Headscale es casi ideologica: Tailscale es mas comodo y funciona inmediatamente, Headscale da control total a cambio de mantener un servicio mas. Yo he acabado usando ambos en distintos contextos. Y si te quedas en WireGuard puro, invierte en automatización desde el dia uno: una plantilla para generar configuraciones, un repositorio git para versionar y un proceso claro de revision.
WireGuard es una herramienta excelente pero no es magia. Su poder aparece cuando se usa con disciplina: claridad sobre la identidad de cada nodo, reglas minimas para el enrutado y un plan claro para cuando la malla crezca. Con estas tres piezas, una malla WireGuard puede durar anios sin drama. Sin ellas, cualquier solución acaba siendo fragil.
