Relais Nebula configuré mais inutilisé : trois réglages à vérifier

Vous avez ajouté un hôte relais, inscrit son adresse Nebula dans une configuration, et les deux pairs ne se parlent toujours pas. Cela vient du fait qu’un chemin de relais exige trois déclarations distinctes qui doivent concorder, et une seule d’entre elles se trouve sur la machine que vous avez probablement modifiée. Je l’ai vérifié deux fois : une fois où l’hôte de transfert n’avait jamais reçu le rôle de relais, et une fois où les réglages avaient été écrits du mauvais côté de la connexion. La séquence ci-dessous contrôle le rôle, l’annonce et l’autorisation dans cet ordre, et chaque étape dispose d’une commande qui vous dit si vous devez continuer.

Cartographiez les trois rôles avant de modifier une configuration

Nebula attribue une tâche à chaque hôte, et ces tâches ne sont pas héritées. Un lighthouse répond aux questions du type « où se trouve ce pair » pour que les hôtes se trouvent mutuellement. Un relais transfère le trafic entre deux pairs qui n’ont pas de chemin direct fonctionnel. Un hôte ordinaire ne fait ni l’un ni l’autre. Les trois réglages qui comptent vivent sur trois machines différentes, et c’est pourquoi une configuration client qui semble complète peut laisser les deux pairs en attente.

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

Un seul symptôme sépare les deux classes de panne. Si les deux pairs se listent mutuellement et que le journal montre des tentatives de handshake qui ne se terminent jamais, la découverte fonctionne et le chemin de données est bloqué par du NAT ou par un pare-feu. Si un pair n’apprend jamais l’adresse de l’autre, le problème vient du lighthouse ou de sa carte d’hôtes statique, et les réglages de relais ne peuvent pas y remédier.

Vérifiez quelle configuration chaque hôte a réellement chargée avant de modifier quoi que ce soit d’autre. Une unité qui lit un autre chemin que le fichier que vous avez modifié est une cause fréquente et embarrassante du fait que « la modification n’a rien changé » :

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

La ligne de version compte dans un parc hétérogène. La gestion des relais, le comportement de perçage et les clés de configuration acceptées ne sont pas identiques d’une version à l’autre, ne partez donc pas du principe qu’une version ancienne comprend une section pour laquelle elle n’a pas été écrite. Alignez les hôtes sur la même série mineure, exécutez ensuite nebula -test -config /etc/nebula/config.yml sur chaque hôte et comparez la sortie avant de déboguer un transport que le code n’implémente pas.

Activez le rôle de transfert sur l’hôte relais

Le rôle de relais est un seul drapeau sur l’hôte de transfert, et il est distinct du rôle de lighthouse. Un hôte dont la découverte est activée et le transfert par relais désactivé ne reste qu’un service de découverte. Sur le relais :

relay:
  am_relay: true

Ce drapeau déclare une intention ; il ne crée pas de joignabilité. Un relais doit être joignable depuis les deux pairs, ce qui signifie en pratique une adresse publique, de l’UDP entrant sur le port Nebula ouvert dans le pare-feu de l’hôte et dans tout groupe de sécurité cloud, et pas de double NAT devant lui. Vérifiez la socket en écoute, puis surveillez l’arrivée des paquets du pair :

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

Deux limites font gagner du temps plus tard. Un relais n’est pas joignable à travers un autre relais, une chaîne de noms de relais dans une configuration ne remplace donc pas un chemin utilisable vers l’hôte de transfert. Et un relais transmet des paquets ; il n’accorde aucune autorisation, les règles entrantes de la destination décident toujours si le flux relayé est autorisé. Le rôle et ses exigences sont décrits dans la documentation de configuration du relais.

Annoncez le relais depuis la destination, pas depuis le client

C’est l’inversion qui coûte le plus d’heures. La liste de relais appartient à l’hôte que vous cherchez à joindre, car elle indique aux autres pairs quels relais peuvent servir à atteindre cet hôte. La placer sur le client qui ouvre la connexion n’apporte rien pour la direction dont le client a besoin :

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

Les pairs signalent cette liste avec leurs adresses lorsqu’ils se présentent au lighthouse, l’annonce se propage donc par la découverte et non par un échange direct. Si la destination n’atteint aucun lighthouse, sa liste de relais ne se diffuse jamais et un relais correctement configuré reste inactif. Cette panne ressemble exactement à un relais cassé et n’en est pas un.

Donnez à la destination un chemin d’amorçage dans la même passe. La carte d’hôtes statique relie une adresse Nebula à un point de terminaison public pour que le premier handshake ait où aller, et elle a besoin d’une entrée pour le relais si la destination doit accepter du trafic relayé venant d’hôtes qu’elle ne peut pas joindre directement :

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

Laissez le pair qui se connecte utiliser le relais

Le côté initiateur a besoin de sa propre autorisation. relay.use_relays est actif par défaut, le cas à rechercher est donc un false explicite, souvent copié d’un modèle écrit avant l’existence de la fonction de relais ou laissé par une tentative antérieure de forcer des chemins directs :

relay:
  use_relays: true

L’autorisation de ce côté n’est pas la seule barrière. Les règles entrantes de la destination s’appliquent toujours au paquet relayé, et la source qu’elles comparent est l’identité à l’intérieur du tunnel, pas l’adresse du relais lui-même. Quand le handshake relayé aboutit et que l’application échoue encore, lisez le journal de la destination pour connaître la source qu’elle a enregistrée avant de réécrire une règle.

Les réglages de traversée de NAT interagissent avec tout cela. punchy.punch aide deux pairs à ouvrir un chemin direct, et quand il y parvient il n’y a aucun trafic de relais à observer ; c’est une réussite, pas un relais manquant. Une paire qui fonctionne par intermittence signifie généralement que le perçage réussit parfois, testez donc cette paire plusieurs fois au lieu de conclure à partir d’un seul essai.

Vérifiez avec la paire qui a échoué, puis rechargez

Testez les deux hôtes qui ont réellement échoué, avec l’application dont ils ont besoin. Un ping réussi depuis votre poste vers le service du relais lui-même ne prouve rien sur le transfert entre deux autres pairs, et c’est le faux positif le plus courant de toute cette procédure.

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

Rechargez au lieu de redémarrer, et confirmez que le processus en cours a bien repris le fichier que vous avez modifié. Un redémarrage coupe chaque tunnel et rend le test suivant plus difficile à lire, alors qu’un SIGHUP conserve le processus et lui fait relire la configuration :

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload ne fonctionne que si l’unité locale définit ExecReload, et l’unité livrée avec le projet ne le fait pas, systemctl kill -s HUP est donc l’étape qui réussit sur une installation standard. Après le rechargement, lisez le journal pour le chemin de configuration que le processus a ouvert, afin de savoir que le nouveau fichier a été lu et non celui que vous supposiez chargé.

Les réglages de relais et le perçage NAT agissent tous deux sur le chemin ; aucun n’agit sur l’identité. Si la paire échoue encore son handshake alors que am_relay, relays et use_relays sont confirmés dans la configuration en cours, vérifiez que les deux hôtes présentent des certificats émis pour les noms avec lesquels ils sont configurés et que le CA est identique des deux côtés. Gardez la configuration des certificats et du pare-feu figée pendant que vous changez un réglage de transport à la fois, car une modification de certificat et une modification de relais dans le même test ne vous disent rien sur celle qui a déplacé le handshake. Une discordance de nom ou de CA échoue au même endroit qu’un relais introuvable, et c’est pourquoi cette contre-vérification fait partie de la même passe.

Confirmez ensuite que chaque déclaration se trouve dans le fichier auquel elle appartient :

• am_relay: true sur l’hôte de transfert, et cet hôte joignable en UDP des deux côtés.
• relays: nommant l’adresse Nebula de cet hôte sur la destination.
• use_relays: true sur le pair qui ouvre la connexion.
• Règles entrantes sur la destination autorisant toujours la source réelle après le changement de chemin.