Nebula static_host_map: l’adresse qu’un phare ne peut pas donner

Chaque phare peut renseigner un hôte sur tous les autres pairs, sauf sur l’endroit où le phare lui-même réside. Quelque chose doit être connu avant que l’overlay existe, et Nebula place ce quelque chose dans une petite carte. La carte associe une identité overlay à une adresse qui fonctionne sur le réseau ordinaire. Tout ce qui est appris ensuite dépend de l’exactitude de cet appariement.

Deux adresses, deux rôles

Chaque hôte Nebula possède une adresse overlay qui reste fixe pendant que l’appareil se déplace entre les réseaux. Cette adresse est l’identité utilisée par les certificats, les règles de pare-feu et les relations entre pairs, et à elle seule elle ne route nulle part. Le point de terminaison joignable est autre chose : un nom d’hôte ou une adresse sur le réseau sous-jacent plus un port UDP, et il change chaque fois que la machine change d’emplacement. La carte statique est la jointure entre les deux.

Seuls les hôtes qui doivent être appelés à froid figurent dans la carte, ce qui signifie généralement les phares et peut-être un relais. Garder cette liste courte est un objectif de conception, car chaque entrée manuelle devient un fait que quelqu’un doit maintenir. Confondre les deux types d’adresse est l’erreur de configuration habituelle : une adresse publique placée dans la liste des phares ne fait pas démarrer la découverte.

L’identité va là où l’identité est attendue. La joignabilité va dans la carte.

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomie d’une entrée de carte

La clé est l’adresse overlay écrite comme une chaîne entre guillemets, et la valeur est une liste de points de terminaison, si bien qu’une identité peut avoir plusieurs points d’entrée. Chaque point de terminaison porte un hôte et un port, et le port doit correspondre à ce que l’autre côté écoute réellement. La valeur par défaut de Nebula est UDP 4242, ce qui est un point de départ et non une promesse sur votre déploiement.

Plusieurs points de terminaison sont utiles quand un phare a plus d’un chemin d’entrée, par exemple une adresse publique et une adresse privée pour les hôtes du même segment. Le client les essaie dans l’ordre, alors mettez le plus fiable en premier. Pour IPv6, mettez l’adresse entre crochets avant d’ajouter le port ; se tromper produit une erreur d’analyse qui pointe vers la mauvaise ligne.

Un mauvais port produit du silence au lieu d’une erreur, car UDP n’a pas de handshake pour refuser. C’est pourquoi le format de l’entrée mérite d’être vérifié contre la référence static_host_map de Nebula plutôt que de mémoire. La référence couvre aussi les listes de points de terminaison et le comportement d’actualisation DNS.

Le bootstrap doit fonctionner avant l’overlay

Un nom DNS de la carte doit se résoudre via le résolveur dont l’hôte dispose avant tout tunnel, c’est-à-dire le résolveur système ordinaire. Testez-le depuis la même machine, au démarrage, avec l’overlay arrêté. Un nom qui ne se résout que via le DNS propre à l’overlay ne peut pas amorcer l’overlay. Le même test vaut pour la route : une règle de pare-feu qui autorise l’overlay mais pas le premier échange UDP bloque le paquet initial.

Sondez le port avec un outil UDP au lieu de supposer qu’il est ouvert. Confirmez que toute redirection de port sur le chemin vise le bon hôte interne et qu’un chemin de retour existe. Si le nom d’hôte se résout en plusieurs adresses, testez chacune, car un client peut choisir une adresse que vous n’avez jamais vérifiée.

Les entrées statiques sont appelées directement et ne consultent jamais un phare. C’est pourquoi une panne ici ressemble à un simple délai d’attente sans aucun pair impliqué.

Ce qui se passe après le premier handshake

Une fois qu’un hôte atteint un phare, il apprend les pairs et leurs adresses joignables sans autres entrées manuelles. Les hôtes qui ont bougé depuis la dernière connexion deviennent découvrables par ce canal. C’est la récompense d’avoir gardé la carte manuelle petite.

Les hôtes peuvent aussi annoncer leurs propres adresses joignables supplémentaires, et c’est ainsi qu’un pair derrière une adresse publique connue aide les autres à le trouver. Ces annonces sont apprises, pas saisies dans la carte statique.

Le comportement d’actualisation compte pour les points de terminaison écrits comme noms DNS, car une adresse résolue peut changer pendant que le processus continue de tourner. Les réglages de Nebula contrôlent la façon dont ces recherches se font, y compris quel résolveur est utilisé, alors lisez-les au lieu de supposer la valeur par défaut du système. Sur un hôte dont le résolveur change quand un tunnel monte, le mauvais réglage peut transformer un bootstrap fonctionnel en un nom qui cesse de se résoudre en pleine session. Épingler la recherche à un résolveur stable est souvent la différence entre un overlay fiable et un overlay intermittent.

Quand la découverte fonctionne et qu’un pair non

Si les phares sont joignables et que la plupart des pairs se connectent, le bootstrap n’est pas le problème. La paire restante soit ne trouve pas de chemin utilisable l’un vers l’autre, soit échoue au-delà de la joignabilité. Ajouter une autre orthographe de l’adresse du phare ne répare aucun des deux cas.

Vérifiez la paire avant de modifier la carte sur laquelle tout le reste repose déjà. Un changement de carte perturbe chaque hôte, c’est donc la dernière chose à toucher, pas la première.

Commencez par des certificats de la même autorité, car un handshake rejeté peut de loin ressembler à un pair injoignable. Vérifiez ensuite si la paire peut établir un chemin direct et si un relais est configuré pour les réseaux qui refusent le trafic direct. Un relais ajoute un saut et une dépendance, mais c’est une réponse prise en charge, et réparer le chemin de la paire est une autre tâche que réparer la découverte.