Nebula est né d’une difficulté d’ingénierie bien concrète. Vers la fin de 2016, le réseau de production de Slack connaissait une expansion rapide, et la solution IPSec utilisée alors pour relier les serveurs entre les régions commençait à montrer ses limites. Chaque paquet traversant les régions devait passer par un hôte tunnel IPSec, ajoutant un saut de latence sans contrepartie.

Plus problématique encore : à mesure que le réseau s’étendait sur plusieurs fournisseurs de cloud et des dizaines de sites, les « groupes de sécurité » propres à chaque fournisseur devenaient incompatibles entre eux, et les règles de pare-feu se réduisaient à une gestion grossière par plages d’adresses IP.

Nate Brown et Ryan Huber ont évalué toutes les solutions disponibles à l’époque. Aucune ne satisfaisait simultanément les exigences de Slack en matière de performance, d’échelle et de simplicité opérationnelle. Ils ont donc décidé de construire la leur. Le résultat de cette décision s’appelle Nebula, un système de réseau superposé qui, depuis le milieu de l’année 2017, porte l’essentiel du trafic réseau de Slack en interne, et qui n’a été basculé en open source qu’en novembre 2019.

Le principe de conception central de Nebula peut se résumer ainsi : intégrer l’identité numérique directement dans le tunnel chiffré, afin d’éliminer ce problème de distribution des clés qui empoisonne les architectures VPN traditionnelles. En effet, dans la plupart des réseaux superposés bâtis sur WireGuard, le chiffrement est assuré par WireGuard, mais la gestion des clés, l’authentification et le contrôle d’accès reposent sur un système latéral construit séparément. Cela signifie que lorsqu’une nouvelle machine rejoint le réseau, le service de coordination doit prévenir tous les nœuds existants pour qu’ils mettent à jour leur configuration. À l’échelle de Slack, c’est-à-dire plus de cinquante mille machines de production, chaque nouveau nœud impliquait d’informer cinquante mille nœuds de son existence, une approche intenable.

La solution de Nebula consiste à faire porter l’identité par des certificats PKI. Chaque machine reçoit, avant de rejoindre le réseau, un certificat signé par une autorité de certification, dans lequel sont encodés son adresse IP au sein du réseau superposé, son nom, ainsi que son appartenance à des groupes de sécurité définis par l’utilisateur. Lorsque deux machines communiquent pour la première fois, elles échangent et vérifient directement leurs certificats, confirment mutuellement leur identité, puis établissent un tunnel chiffré. Ce processus ne nécessite aucune distribution préalable de clés par un tiers, ni l’intervention d’un plan de contrôle pour coordonner les échanges. Selon les mots de Ryan Huber, ils voulaient un protocole qui traite directement l’identité et le transport, plutôt que d’accoler une identité à un VPN distinct.

Cette logique de décentralisation se retrouve également dans le mécanisme de découverte des nœuds. Il existe dans un réseau Nebula une catégorie de nœuds appelés Lighthouse (phare en français), dont l’unique fonction est de servir d’annuaire : indiquer à une machine comment en trouver une autre. Les Lighthouse ne communiquent pas entre eux et ne participent à aucun transfert de données. Si un réseau compte six Lighthouse et que cinq d’entre eux tombent en panne, le dernier continue de fonctionner normalement, et les chemins de trafic de l’ensemble du réseau restent inchangés.

Nebula au quotidien

Entre machines Linux, l’utilisation de Nebula au quotidien est un régal. Déjà parce qu’il n’y a pas besoin d’établir le réseau : celui-ci est automatiquement actif sous forme de service Nebula systemd au boot de la machine.

Dit autrement, pas besoin de rien lancer de spécial, tous les ping 192.168.100.x répondent. Et la connexion perdure en toutes circonstances, y compris si le chemin entre les deux machines change parce qu’on vient d’activer une connexion VPN wireguard par exemple.

Nebula s’en fiche, s’il existe un chemin entre 2 machines à un instant t il est emprunté. S’il change en cours de route, c’est transparent. Incroyable.

Pour relier ses employés en télétravail au SI de l’entreprise c’est idéal.

Installation et utilisation de Nebula

Dans ce tutoriel, nous allons faire une installation simple mais didactique entre un VPS Ubuntu sur Internet, qui sera le lighthouse de notre réseau privé chiffré, et un client laptop Linux Ubuntu.

Le produit s’installe par (à faire sur toutes les machines Ubuntu du réseau) :

sudo apt install nebula

Sur une machine privilégiée pour la configuration, nous allons créer un répertoire dédié ~/nebula et dans ce répertoire nous allons commencer par créer notre autorité de certification, par la commande :

nebula-cert ca -name "Ma Super CA"

Les fichiers ca.crt et ca.key sont alors créés.

Attention : Soyez attentif au fait que la clé (ca.key) est strictement confidentielle. Cette clé ne doit absolument jamais être partagée. Son usage doit être limité à la génération de nouveaux certificats.

Si jamais vous voulez voir les détails à propos d’un certificat, ou dans ce cas de l’autorité de certification, vous pouvez utiliser la commande nebula-cert print. Voici un exemple de la sortie de la commande sur l’autorité de certification que nous venons tout juste de générer :

nebula-cert print -path ca.crt
{
        Details {
                Name: Ma Super CA
                Ips: []
                Subnets: []
                Groups: []
                Not before: 2025-07-09 20:24:48 +0000 UTC
                Not After: 2126-07-09 20:24:48 +0000 UTC
                Is CA: true
                Issuer:
                Public key: xxx
        }
        Fingerprint: xxx
        Signature: xxx
  }

Configuration de la lighthouse (le VPS sur Internet)

Pour générer le certificat de la lighthouse, nous allons taper la commande (qui attribue notamment l’adresse IP 192.168.100.1 pour la lighthouse dans notre réseau Nebula) :

nebula-cert sign -name "lighthouse" -ip "192.168.100.1/24"

Ensuite nous mettons les 2 fichiers créés (lighthouse.crt et lighthouse.key) dans /etc/nebula sur le serveur. On copie également ca.crt dans ce répertoire /etc/nebula.

Il faut ensuite créer le fichier /etc/nebula/config.yml et mettre dedans :

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/lighthouse.crt
  key: /etc/nebula/lighthouse.key

static_host_map:
  # Format: "IP_Nebula": ["IP_publique:port"]
  "192.168.100.1": ["VOTRE_IP_PUBLIQUE:4242"]

lighthouse:
  am_lighthouse: true
  interval: 60

listen:
  host: 0.0.0.0
  port: 4242

punchy:
  punch: true
  punch_back: true

tun:
  dev: nebula1
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300

logging:
  level: info
  format: text

firewall:
  conntrack:
    tcp_timeout: 12m
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  outbound:
    - port: any
      proto: any
      host: any

  inbound:
    - port: any
      proto: any
      host: any

Configuration des nodes (clients)

Pour chaque client, il faut créer une paire certificat/clé privée. Par exemple pour le node1 (qui aura pour adresse IP 192.168.100.2 dans le réseau Nebula) :

nebula-cert sign -name "node1" -ip "192.168.100.2/24" -groups "clients"

Cette commande crée les fichiers node1.crt et node1.key qu’il faut copier dans le répertoire /etc/nebula du PC client correspondant, ainsi qu’y copier ca.crt.

Sur chaque client il faut également créer le fichier /etc/nebula/config.yml et y mettre comme contenu :

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/asus.crt
  key: /etc/nebula/asus.key

static_host_map:
  "192.168.100.1": ["VOTRE_IP_PUBLIQUE_LIGHTHOUSE:4242"]

lighthouse:
  am_lighthouse: false
  interval: 60
  hosts:
    - "192.168.100.1"

listen:
  host: 0.0.0.0
  port: 0  # Port éphémère

punchy:
  punch: true
  punch_back: true

tun:
  dev: nebula1
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300

logging:
  level: info
  format: text

firewall:
  conntrack:
    tcp_timeout: 12m
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  outbound:
    - port: any
      proto: any
      host: any

  inbound:
    - port: any
      proto: any
      host: any

Démarrage du service Nebula

Que ce soit sur la lighthouse ou sur les clients Linux, on lance Nebula sous forme de service systemd.

Pour cela, il suffit de créer sur chaque machine le fichier /etc/systemd/system/nebula.service et d’y mettre le contenu suivant :

[Unit]
Description=Nebula Network
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/nebula -config /etc/nebula/config.yml
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Sur chaque machine, le service s’active une bonne foi pour toutes par la série de commandes suivantes :

sudo systemctl daemon-reload
sudo systemctl enable nebula
sudo systemctl start nebula
sudo systemctl status nebula

Sur chaque machine une nouvelle interface réseau appelée Nebula1 est créée.

Il n’y a plus qu’à vérifier que le ping entre machines fonctionne bien.

En conclusion, on peut voir qu’obtenir une configuration basique fonctionnelle est assez facile. Bien sûr Nebula permet d’en faire bien plus, notamment en attribuant des droits fins en fonction des groupes dans lesquels les machines sont déclarées.

L’avantage du produit est qu’une fois qu’il est configuré et activé sous forme de service, il est par définition actif, il n’y a plus de connexion ou de déconnexion au réseau overlay à faire. Tout le trafic de la plage 192.168.100.x passe par le réseau chiffré qu’on vient de créer, même si un lien wireguard est activé en cours de route.