Nebula lleva seis años en el mundo, liberada por Slack en 2019 como herramienta interna para conectar su flota distribuida, y sin embargo sigue siendo mucho menos conocida que WireGuard o Tailscale. Esto sorprende porque su diseño resuelve bien un problema concreto: conectar cientos o miles de nodos en malla, cada uno con su identidad criptográfica, sin depender de un servidor central que cifre y descifre todo el tráfico. Este marzo he terminado de migrar una red interna a Nebula y el aprendizaje merece un texto.
La idea de este post no es un tutorial de instalación (la documentación oficial es clara) sino entender cómo está construido, compararlo con las alternativas más populares y contar qué he aprendido en la práctica.
Arquitectura: lighthouses y mesh
Nebula construye un plano de control mínimo y un plano de datos completamente en malla. Los nodos que forman la red se conocen entre ellos mediante un sistema de descubrimiento llamado lighthouse: uno o varios nodos designados que llevan un registro de las direcciones públicas de cada peer. Cuando un nodo nuevo quiere hablar con otro, pregunta al lighthouse dónde encontrarlo y luego establece la conexión directa punto a punto.
La clave es que esa conexión no pasa por el lighthouse. Éste solo facilita el descubrimiento inicial y ocasionalmente ayuda a atravesar NAT, pero el tráfico real fluye directamente entre los dos nodos implicados. Esto es muy diferente de una VPN tradicional con concentrador, donde todo el tráfico pasa por un servidor central que cifra y descifra paquetes. En una red con diez nodos no se nota; en una red con quinientos, la diferencia es enorme tanto en latencia como en coste de infraestructura.
El cifrado usa curvas elípticas modernas (Curve25519 para el intercambio de claves, AES-GCM o ChaCha20-Poly1305 para los datos) y el handshake es un Noise Protocol Framework, el mismo esquema subyacente que usan WireGuard y Signal. La seguridad criptográfica es sólida y está razonablemente auditada.
PKI propia y firma de identidad
Una diferencia importante frente a WireGuard es que Nebula trae su propia PKI. Cada nodo tiene un certificado firmado por una autoridad certificadora local, y ese certificado lleva embebidas la IP que el nodo tendrá dentro de la VPN y los grupos a los que pertenece. Los grupos son etiquetas arbitrarias (por ejemplo «db», «web», «monitoring») que después se usan para definir reglas de firewall distribuidas.
Esto tiene tres consecuencias prácticas. Primera, la asignación de IPs es determinista y centralizada en la firma del certificado; no hay DHCP dentro de la VPN. Segunda, el firewall interno puede expresar políticas mucho más expresivas que un simple rango de IPs: «los nodos del grupo web pueden hablar a los del grupo db en puerto 3306, nadie más puede». Tercera, la revocación de un nodo comprometido se hace añadiéndolo a una lista de revocación que los lighthouses distribuyen al resto.
La desventaja de este esquema es que añadir un nodo nuevo implica firmar un certificado con la CA, lo cual introduce un paso administrativo que WireGuard no tiene. La ventaja es que la identidad criptográfica y la identidad de red están ligadas, lo cual reduce los errores de configuración y permite razonar sobre la seguridad con más claridad.
Comparación con WireGuard y Tailscale
WireGuard es más sencillo de desplegar y su integración con el kernel de Linux es impecable. Si necesitas conectar dos o tres nodos, o una fuerza de trabajo remota al interior de una red, WireGuard es casi siempre la elección correcta. Es rápido, está muy probado y el modelo mental es mínimo: claves públicas, claves privadas, peers con allowed-ips.
Donde WireGuard pierde es en escala. Para conectar cincuenta nodos en malla completa necesitas generar cincuenta configuraciones que cada una lista a los otros cuarenta y nueve peers, con sus allowed-ips, y actualizarlas cada vez que cambia algo. Existen herramientas encima de WireGuard que orquestan esto (wg-meshconf, innernet), pero la solución nativa no está pensada para mallas grandes.
Tailscale resuelve el problema de la malla de otra manera: añade un plano de control centralizado como servicio alojado por ellos, con una UI agradable y capacidades como MagicDNS y ACLs declarativas. La experiencia es excelente para equipos pequeños y medianos, y el modelo es muy afinado. El coste es la dependencia del servicio Tailscale y el hecho de que la autenticación pasa por su infraestructura (aunque el tráfico de datos no).
Nebula se sitúa en un punto intermedio: es autoalojable (nada de SaaS) como WireGuard, pero está diseñado desde el principio para malla con descubrimiento. No tiene la UI ni las facilidades de Tailscale, pero tampoco tiene el coste operativo de WireGuard a escala. Es la elección natural cuando quieres una VPN en malla grande y sin depender de un proveedor externo.
Lo que he aprendido desplegándola
Hay varios detalles que la documentación cuenta pero que solo aprecias en producción.
El primero es que la PKI es tu eslabón crítico. La clave privada de la CA debe vivir en algún sitio fuera de la red (un disco cifrado, un HSM, un secreto en un gestor), porque quien tenga acceso a ella puede firmar certificados arbitrarios y entrar en la red como cualquier nodo. He visto configuraciones donde la CA vivía en el mismo lighthouse que rotaba tráfico, lo cual es un antipatrón claro.
El segundo es que los lighthouses deben ser redundantes. Si el único lighthouse cae, los nodos ya conectados siguen hablándose sin problema, pero los nodos nuevos o los que pierdan su tabla de peers no podrán reconectar. Tener al menos dos en zonas geográficas distintas es lo razonable, y configurarlos en los nodos finales como lista.
El tercero es que el firewall embebido en Nebula es potente pero requiere disciplina. Las reglas se definen en el archivo de configuración de cada nodo y deben mantenerse consistentes. Para redes grandes conviene generar esas reglas desde una fuente común (Terraform, Ansible, un script) en lugar de editarlas a mano en cada máquina.
El cuarto es que la integración con Docker y Kubernetes funciona pero hay matices. Dentro de un contenedor se puede correr nebula como proceso, exponer la interfaz tun al contenedor vecino o usar un sidecar. En Kubernetes existen proyectos como nebula-operator que simplifican la gestión, pero todavía no están al nivel de madurez que tiene tailscale-operator.
Cuándo compensa elegir Nebula
Nebula brilla cuando se cumplen varias condiciones a la vez. Una red distribuida con muchos nodos (docenas o cientos) que necesitan hablar entre sí de forma directa. Un requisito de autoalojamiento por razones de cumplimiento o soberanía. Un equipo con capacidad para operar una PKI y mantener configuraciones desde una fuente de verdad declarativa. Un patrón de tráfico donde el paso por un concentrador único sería un cuello de botella real.
Si tu escenario es más pequeño (dos oficinas, un equipo remoto de diez personas, un par de servidores en nubes distintas), WireGuard puro o Tailscale probablemente cubren mejor la necesidad y con menos complejidad. La gracia de Nebula es resolver bien el caso intermedio-grande sin depender de un SaaS, y es ahí donde no tiene competencia directa.
Para lo que queda de 2025, me interesa ver cómo evoluciona el ecosistema. Hay trabajo en mejor interoperabilidad con IPv6, en tooling gráfico sobre la API de control y en patrones de despliegue para Kubernetes. El proyecto tiene la virtud poco glamurosa de no querer ser todo para todos: hace una cosa, la malla en autoalojado, y la hace bien. Esa claridad de alcance es lo que me ha hecho elegirlo para la red que he migrado este mes.
