Qué es NetBird: la alternativa open source a Tailscale que puedes hostear (2026)

agosto 24, 2026 Alfonso Moreno | Sysadmin Senior 130 Visitas 10 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Qué es NetBird y por qué migrar de WireGuard puro

Si llevas años conectando oficinas, servidores y laptops con WireGuard “a mano”, probablemente ya sabes lo que es mantener un nodo nuevo: generar claves, firmar el wg-public.key, abrir puertos en el firewall, configurar el AllowedIPs y rezar para que el NAT no te fastidie el primer ping. NetBird automatiza todo ese flujo sobre la misma base criptográfica de WireGuard, pero añade un plano de control que decide por ti quién habla con quién y cómo se conectan los peers aunque estén detrás de NAT doble o CGNAT. Es, en la práctica, una alternativa open source a Tailscale escrita en Go, con SSO/MFA, ACL granulares y un panel web que se siente más producto que proyecto de fin de semana.

En este artículo vas a ver qué problema concreto resuelve NetBird, en qué se diferencia de un WireGuard “manual” o de Tailscale (que es su espejo SaaS), cómo instalarlo en 10 minutos con el setup unificado de v0.65+ y cuándo conviene quedarte con WireGuard puro en vez de añadir la capa de control. Todo verificado contra los repos oficiales en septiembre 2026 (versión actual v0.78.1, 28.9k estrellas en GitHub, 1.7k forks, licencia BSD-3 para el cliente y AGPLv3 para el servidor).

El problema: WireGuard es criptografía, no es gestión

WireGuard es brillante para lo que hace: un túnel UDP con criptografía moderna (Curve25519, ChaCha20, Poly1305) que cabe en pocos miles de líneas de código y va más rápido que OpenVPN o IPsec en la mayoría de escenarios. Lo que pasa es que WireGuard deliberadamente no hace gestión: ni distribúye claves, ni descubre peers, ni decide quién se conecta con quién, ni maneja NAT traversal. Cada nodo nuevo implica editar manualmente wg0.conf en el servidor, regenerar pares de claves, firmar la peer_public_key y rezar para que tu firewall no esté bloqueando el puerto 51820.

Si tienes tres o cuatro nodos en casa, se puede vivir con eso. Cuando tienes una flota distribuida entre la oficina, dos servidores VPS, el portátil del equipo comercial que viaja y tres containers en un clúster Proxmox, mantener la topología WireGuard a mano se vuelve un trabajo de medio tiempo. Ahí entran los mesh VPN con plano de control: Tailscale (cerrado), ZeroTier (cerrado), Headscale (open source compatible con Tailscale) y NetBird (open source con su propio protocolo sobre WireGuard).

Qué hace NetBird exactamente

NetBird es una red overlay peer-to-peer construida sobre WireGuard con un servidor de coordinación que maneja el resto. Cuando instalas el cliente NetBird en un dispositivo y lo registras contra tu servidor de gestión, pasan tres cosas automáticamente:

Descubrimiento de peers: el servidor sabe qué dispositivos existen en tu red y le dice a cada uno con quién puede hablar según las ACL que definiste.
Distribución de claves: NetBird genera los pares de claves WireGuard por ti, firma las claves públicas y las rota periódicamente (cada 24h en el setup por defecto, configurable).
NAT traversal: cuando dos peers están detrás de NAT, NetBird intenta primero una conexión directa hole-punching UDP; si falla, usa servidores relay TURN-style que el proyecto opera como open source o que puedes hostearte tú mismo.

El resultado, desde tu punto de vista, es que después de instalar el cliente y hacer login con tu IdP (Google Workspace, Okta, Azure AD, Keycloak, Authentik), los nodos se ven entre sí como si estuvieran en una LAN privada con IPs del rango 100.64.0.0/10 (mismo rango que Tailscale, mismo CGNAT-style addressing). Si quieres acceder al servidor Postgres en tu homelab desde el portátil del café, NetBird enruta el tráfico sin que tengas que tocar un solo wg-quick.

Qué hay de nuevo en 2026 (v0.65 a v0.78)

El proyecto ha madurado mucho en los últimos 12 meses. Los hitos que más importan para alguien evaluándolo hoy:

v0.65 (febrero 2026): unified server binary. Antes había que correr tres containers separados (management, signal, relay); desde v0.65 un solo binario maneja los los. Esto reduce el setup self-hosted de “tres servicios con certificados compartidos” a “un container, una variable de entorno”.
v0.72 (junio 2026): nuevo dashboard con vista de topología (ya tenías el listado de peers; ahora ves el grafo de qué habla con qué) e identity-aware SSH que mete tu key SSH en la sesión vía el IdP en lugar de tener que distribuir authorized_keys a mano.
v0.74 (julio 2026): posture checks dinámicos. NetBird puede denegar acceso si el cliente no cumple reglas definidas en el servidor (firewall activo, antivirus corriendo, OS específico, geo, red concreta). Es el equivalente self-hosted del device trust de Jamf/Intune pero dentro de la VPN mesh.
v0.78 (septiembre 2026): peer-based routers en el network map. Antes había que definir rutas estáticas a redes que no son parte del mesh (por ejemplo, la LAN 192.168.1.0/24 detrás de tu homelab); ahora un peer puede declararse router para una red y NetBird propaga la ruta al resto de peers automáticamente.

Si tu homelab corre un servidor NetBird v0.65+ y tus peers están actualizados, la experiencia operativa es comparable a Tailscale pero con todo el control en tu lado.

Setup en 10 minutos con el unified server

El setup self-hosted mínimo viable en 2026 es un solo container. En un VPS cualquiera (1 vCPU, 1 GB RAM alcanza para una flota pequeña de 20-30 dispositivos):

# 1. Crear el directorio de configuración
sudo mkdir -p /etc/netbird && cd /etc/netbird
# 2. Generar el setup key y domain (NetBird usa wildcard DNS para los relays)
sudo docker run --rm netbirdio/netbird:v0.78.1 setup 
  --domain netbird.tudominio.com 
  --dashboard-domain netbird.tudominio.com
# Esto genera un archivo setup.env con NETBIRD_DOMAIN, NETBIRD_ADMIN_USER,
# y un JWT_SECRET aleatorio de 32 bytes. Lo único que tienes que apuntar:
# el wildcard DNS *.netbird.tudominio.com al IP del VPS.
# 3. Levantar el servicio único
sudo docker compose up -d
# 4. Verificar que está corriendo
curl -k https://netbird.tudominio.com/api/health
# {"status":"ok"}
# 5. Instalar el cliente en tu laptop
curl -fsSL https://pkgs.netbird.io/install.sh | sh
sudo netbird up --management-url https://netbird.tudominio.com 
  --setup-key <u-setup-key-del-paso-2>

Si la salida del paso 4 devuelve 200 OK y el paso 5 termina con connected, ya tienes NetBird funcionando. El primer usuario que se loguea queda como administrador del dashboard, así que regístráte tú primero antes de compartir el setup key con nadie.

Cuándo NO usar NetBird y quedarse con WireGuard puro

No todo necesita un plano de control. NetBird suma valor real a partir de cierto tamaño de flota; por debajo de eso, es complejidad que no se amortiza:

1-3 nodos en la misma red privada: WireGuard punto-a-punto con un wg-quick en cada lado es más simple, más rápido y no introduce una pieza más que mantener actualizada.
Conectividad site-to-site pura sin roaming: si tus oficinas tienen IP pública fija y solo necesitas que se vean entre sí, una config WireGuard clásica con PersistentKeepalive es lo correcto.
Edge devices muy restringidos: el cliente NetBird ocupa ~25 MB en disco y ~30 MB en RAM; en un router OpenWrt con 64 MB de RAM esto sí pesa. WireGuard cabe en mucho menos.
Compliance estricto que prohibe terceros: si tu auditor te exige que NADA pase por un relay de un tercero (ni siquiera cifrado), NetBird self-hosted requiere configurar relays propios; WireGuard puro no necesita relays.

Para todo lo demás (equipo distribuido, BYOD, contractors que necesitan acceso temporal a recursos internos, infraestructura híbrida on-prem + cloud) NetBird o Tailscale son la respuesta correcta.

NetBird vs Tailscale: la diferencia real

Funcionalmente NetBird y Tailscale hacen lo mismo. La diferencia operativa:

Aspecto	NetBird	Tailscale
Código del cliente	Open source BSD-3	Open source BSD-3 (cliente)
Servidor de control	Open source AGPLv3, self-hostable	Cerrado, solo SaaS de Tailscale
SSO / MFA	IdP propio: Google, Okta, Azure AD, Keycloak, Authentik, Zitadel	IdP propio + mismas opciones
Posture checks	Sí desde v0.74 (firewall, AV, OS, geo)
Identity-aware SSH	Sí desde v0.72	Sí (Tailscale SSH)
Costo	Gratis self-hosted; SaaS tiene tier gratis limitado	Gratis hasta 100 dispositivos personal; planes empresariales
Lock-in	Ninguno, todo en tu infra	Tienes que confiar en la operación de Tailscale Inc

Si tu prioridad es open source real end-to-end y tienes capacidad de operar el servidor (un container en un VPS chico alcanza), NetBird es la respuesta. Si quieres delegar toda la operación a un vendor maduro y pagar el SaaS, Tailscale sigue siendo la opción más pulida del mercado.

El truco que nadie te cuenta: el relay server

NetBird intenta siempre conexión peer-to-peer directa entre dos clientes. Cuando los dos peers están detrás de NAT y el hole-punching falla, el tráfico pasa por un relay server TURN-style. Hay dos modos:

Relay público operado por NetBird Inc: gratis, anonimiza tu tráfico (no sabe qué peers se comunican, solo forwardea paquetes cifrados WireGuard). Por defecto el cliente intenta primero estos relays.
Relay propio self-hosted: corre un container extra netbirdio/netbird-relay, declaras tu relay en el management con --relay-server, y los peers prefieren tu relay sobre el público.

Para uso personal y PYMEs el relay público basta. Si tienes compliance estricto o quieres minimizar dependencia externa, hostear el relay propio es ~15 minutos adicionales en el setup. Documentación oficial: docs.netbird.io/selfhosted/relay.

Verificación post-instalación

Después del setup, vale la pena confirmar tres cosas que se rompen en silencio:

# 1. Los peers se ven entre sí (debe listar al menos 2 IPs 100.x.x.x)
sudo netbird status
# 2. Hay tráfico real entre ellos (no solo se "ven" sino que responden)
ping 100.64.0.1
nc -zv 100.64.0.1 22
# 3. El dashboard muestra la topología correcta
# Abrir https://netbird.tudominio.com y verificar que aparece tu laptop,
# tu servidor y los peers conectados con el estado "Connected" verde.

Si el paso 1 muestra cero peers conectados pero el dashboard dice que están “Connected”, casi siempre es un problema de DNS para el wildcard *.netbird.tudominio.com. verifica con dig +short netbird.tudominio.com que resuelve a la IP del VPS.

Conclusión

NetBird en 2026 (v0.78.1) es una alternativa open source madura a Tailscale para quienes quieren todo el control en su lado. Setup self-hosted en 10 minutos con el unified server, mismas features de Zero Trust que el SaaS, y sin lock-in. Para una flota distribuida con más de 3-4 nodos y/o necesidad de SSO + posture checks, es la opción correcta.

Preguntas frecuentes

¿Por qué Qué es NetBird: la alternativa open source a Tailscale que puedes hostear (2026) es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Qué es NetBird: la alternativa?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Qué es NetBird: la alternativa?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Qué es NetBird: la alternativa y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Qué es NetBird: la alternativa?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.