Nebula: la VPN overlay de Slack explicada

Actualizado: 2026-05-03

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.

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.

Puntos clave

• Nebula construye un plano de control mínimo (lighthouses para descubrimiento) y un plano de datos completamente en malla: el tráfico real fluye directamente entre nodos, no pasa por el lighthouse.
• Trae PKI propia: cada nodo tiene un certificado firmado por una CA local, con la IP y los grupos embebidos, lo que permite reglas de firewall expresivas y revocación limpia.
• Es la elección natural cuando quieres malla grande auto-alojada sin depender de un SaaS: Nebula hace lo que WireGuard no escala a hacer nativamente y lo que Tailscale hace con SaaS.
• La CA es el eslabón crítico: debe vivir fuera de la red, nunca en el mismo nodo lighthouse.
• Los lighthouses deben ser redundantes: si el único cae, los nodos nuevos no pueden reconectar.

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. 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.
• Los grupos a los que pertenece (etiquetas arbitrarias: «db», «web», «monitoring»).

Los grupos se usan para definir reglas de firewall distribuidas. Por ejemplo: «los nodos del grupo web pueden hablar a los del grupo db en puerto 3306, nadie más puede».

Esto tiene tres consecuencias prácticas:

1. La asignación de IPs es determinista y centralizada en la firma del certificado; no hay DHCP dentro de la VPN.
2. El firewall interno puede expresar políticas muy expresivas, mucho más allá de un simple rango de IPs.
3. La revocación de un nodo comprometido se hace añadiéndolo a una lista de revocación que los lighthouses distribuyen.

La desventaja 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, reduciendo errores de configuración.

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. Ver nuestra guía de WireGuard mesh fácil para casos de escala pequeña.

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, y actualizarlas cada vez que cambia algo. Existen herramientas encima de WireGuard que orquestan esto, 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. El coste es la dependencia del servicio Tailscale. Para una alternativa auto-alojada del plano de control de Tailscale, ver también Headscale como alternativa libre.

Nebula se sitúa en un punto intermedio: auto-alojable como WireGuard, pero 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 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:

1. 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: un antipatrón claro.

2. 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.

3. 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.

4. 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 de 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 auto-alojamiento 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.

El proyecto tiene la virtud poco glamurosa de no querer ser todo para todos: hace una cosa, la malla en auto-alojado, y la hace bien. Esa claridad de alcance es lo que me ha hecho elegirlo para la red que he migrado este mes.