Nebula advertise_addrs ou static_host_map : choisir selon le propriétaire

Les réglages static_host_map et advertise_addrs placent tous deux une adresse devant un peer, et ils répondent à des questions différentes. L’un est un fichier local listant une adresse overlay et le point de terminaison underlay à composer. L’autre est un hôte qui dit à ses phares quels points de terminaison supplémentaires peuvent l’atteindre. La propriété est la vraie différence : la carte est maintenue par tous ceux qui en ont besoin, l’annonce par l’hôte lui-même.

Décidez selon qui possède l’information

Chaque peer changeant dans le fichier statique de chaque peer est une tâche de maintenance qui croît avec le carré de la flotte. C’est la raison pratique de recourir à l’autre réglage chaque fois que l’hôte lui-même connaît la réponse.

La question de la propriété prédit aussi ce qui se passe lorsqu’une adresse change. Avec une carte statique, quelqu’un doit se rappeler chaque peer qui détient l’ancienne entrée. Avec une annonce, l’hôte publie le nouveau point de terminaison et ses phares le relaient, donc le changement reste local à la machine qui a bougé.

Bootstrap a toujours besoin d’entrées statiques

Un client doit atteindre au moins un phare avant de pouvoir demander à quiconque des autres peers. Ce premier saut ne peut pas venir de la découverte, il vient donc de une entrée statique dans la configuration du client. Faites correctement cette unique entrée et le reste de l’overlay peut être appris.

Une entrée de carte associe une adresse Nebula à un ou plusieurs points de terminaison IP ou DNS joignables et à des ports. Y garder les phares est normal ; y garder chaque peer est le schéma qui vieillit mal, car chaque nouveau peer signifie modifier des fichiers sur des machines que vous ne contrôlez peut-être pas. Gardez la liste assez courte pour qu’une personne puisse encore la vérifier en la lisant.

Annoncez quand l’hôte connaît le point de terminaison

Un hôte derrière une redirection de ports est joignable à une adresse publique qui n’est affectée à aucune de ses propres interfaces. Il ne peut pas découvrir cette adresse en se regardant lui-même. advertise_addrs lui permet de publier le point de terminaison via ses phares afin que les autres peers apprennent un chemin qui fonctionne réellement. Le réglage existe précisément parce que l’hôte est la seule partie qui sait que le mappage a été fait.

Utilisez l’adresse et le port que les autres peers peuvent réellement atteindre. Le même raisonnement s’applique à un hôte disposant de plusieurs chemins réseau, où un chemin est préférable pour les peers d’un réseau donné. L’annonce est une affirmation sur l’underlay, pas une demande de quoi que ce soit. Lorsque le mappage change, mettez à jour l’annonce sur l’hôte et laissez la découverte la porter, au lieu de modifier des fichiers statiques dans toute la flotte.

Annoncer n’est pas être joignable

Publier un point de terminaison ne crée pas la règle de redirection du routeur, n’ouvre pas un pare-feu en amont et ne fait pas résoudre un nom DNS. Ce sont des pièces de travail distinctes, et une annonce correcte avec une redirection de port manquante produit exactement la panne que vous cherchiez à corriger. Annoncer est une affirmation sur la joignabilité, pas un mécanisme qui l’établit.

Vérifiez le chemin depuis l’extérieur avant de blâmer la découverte. Un peer qui apprend le point de terminaison mais ne peut pas terminer un handshake a un problème de routage ou de filtrage sur l’underlay, et répéter la même adresse dans les deux réglages n’y changera rien.

Gardez l’adresse overlay distincte du point de terminaison

Le certificat du nœud identifie son adresse Nebula. Les adresses annoncées appartiennent au réseau sous-jacent et peuvent changer sans toucher au certificat. Émettre un nouveau certificat avec une IP overlay différente est une autre opération, avec ses propres conséquences pour chaque relation de confiance qui avait épinglé l’ancienne. Gardez les deux changements séparés dans le runbook, sinon un déplacement de point de terminaison sera enregistré comme une réémission.

Quand le triage bloque, séparez explicitement les deux couches : la découverte renvoie-t-elle le point de terminaison attendu, et un handshake l’atteint-il ? Si la découverte est correcte et que les paquets échouent, le problème est sous l’overlay. Si la découverte est erronée, le problème est dans la carte ou l’annonce, et le correctif appartient là.