Nebula advertise_addrs oder static_host_map: nach Eigentümer wählen
Eine statische Map wird von jedem Peer gepflegt, der sie anwählt; eine beworbene Adresse wird vom Host veröffentlicht. Wähle danach, wer den Endpunkt kennt.
Die Einstellungen static_host_map und advertise_addrs setzen beide eine Adresse vor einen Peer und beantworten unterschiedliche Fragen. Die eine ist eine lokale Datei, die eine Overlay-Adresse und den anzuwählenden Underlay-Endpunkt auflistet. Die andere ist ein Host, der seinen Leuchttürmen mitteilt, welche zusätzlichen Endpunkte ihn erreichen können. Der Eigentümer ist der eigentliche Unterschied: Die Map wird von allen gepflegt, die sie brauchen, die Ankündigung vom Host selbst.
Entscheide danach, wer die Information besitzt
| Setting | Where it lives | Best for |
|---|---|---|
static_host_map | Every peer that needs the entry | Bootstrap endpoints, deliberately fixed paths |
advertise_addrs | The host's own config | Endpoints the host cannot otherwise discover |
Jeder sich ändernde Peer in der statischen Datei jedes Peers ist Wartungsarbeit, die mit dem Quadrat der Flotte wächst. Das ist der praktische Grund, zur anderen Einstellung zu greifen, wann immer der Host die Antwort selbst kennt.
Die Eigentümerfrage sagt auch voraus, was passiert, wenn sich eine Adresse ändert. Bei einer statischen Map muss jemand jeden Peer kennen, der den alten Eintrag hält. Bei einer Ankündigung veröffentlicht der Host den neuen Endpunkt, und seine Leuchttürme geben ihn weiter, sodass die Änderung lokal auf der Maschine bleibt, die umgezogen ist.
Bootstrap braucht weiterhin statische Einträge
Ein Client muss mindestens einen Leuchtturm erreichen, bevor er jemanden nach anderen Peers fragen kann. Dieser erste Sprung kann nicht aus der Erkennung kommen, also kommt er aus einem statischen Eintrag in der Konfiguration des Clients. Mach diesen einen Eintrag richtig, und der Rest des Overlays lässt sich lernen.
Ein Map-Eintrag paart eine Nebula-Adresse mit einem oder mehreren erreichbaren IP- oder DNS-Endpunkten und Ports. Die Leuchttürme dort zu halten ist normal; jeden Peer dort zu halten ist das Muster, das schlecht altert, weil jeder neue Peer das Bearbeiten von Dateien auf Maschinen bedeutet, die du vielleicht nicht kontrollierst. Halte die Liste kurz genug, dass ein Mensch sie noch durch Lesen prüfen kann.
Kündige an, wenn der Host den Endpunkt kennt
Ein Host hinter Portweiterleitung ist unter einer öffentlichen Adresse erreichbar, die keinem seiner eigenen Interfaces zugewiesen ist. Er kann diese Adresse nicht entdecken, indem er auf sich selbst schaut. advertise_addrs lässt ihn den Endpunkt über seine Leuchttürme veröffentlichen, damit andere Peers einen Pfad lernen, der tatsächlich funktioniert. Die Einstellung existiert gerade deshalb, weil der Host die einzige Partei ist, die weiß, dass die Zuordnung vorgenommen wurde.
Verwende die Adresse und den Port, die andere Peers wirklich erreichen können. Dieselbe Überlegung gilt für einen Host mit mehreren Netzwerkpfaden, bei dem ein Pfad für Peers in einem bestimmten Netz bevorzugt wird. Ankündigung ist eine Aussage über das Underlay, keine Anfrage nach irgendetwas. Wenn sich die Zuordnung ändert, aktualisiere die Ankündigung am Host und lass die Erkennung sie tragen, statt statische Dateien flottenweit zu bearbeiten.
Ankündigung ist keine Erreichbarkeit
Das Veröffentlichen eines Endpunkts erzeugt nicht die Weiterleitungsregel des Routers, öffnet keine vorgelagerte Firewall und sorgt nicht dafür, dass ein DNS-Name aufgelöst wird. Das sind getrennte Arbeitsstücke, und eine korrekte Ankündigung mit fehlender Portweiterleitung erzeugt genau den Fehler, den du beheben wolltest. Ankündigung ist eine Behauptung über Erreichbarkeit, kein Mechanismus, der sie herstellt.
Prüfe den Pfad von außen, bevor du die Erkennung beschuldigst. Ein Peer, der den Endpunkt lernt, aber keinen Handshake abschließen kann, hat ein Routing- oder Filterproblem im Underlay, und dieselbe Adresse in beiden Einstellungen zu wiederholen ändert daran nichts.
Halte die Overlay-Adresse vom Endpunkt getrennt
Das Zertifikat des Knotens identifiziert seine Nebula-Adresse. Die angekündigten Adressen gehören zum zugrunde liegenden Netz und dürfen sich ändern, ohne das Zertifikat anzutasten. Ein neues Zertifikat mit einer anderen Overlay-IP ausstellen ist eine andere Operation mit eigenen Folgen für jede Vertrauensbeziehung, die die alte festgehalten hat. Halte die beiden Änderungen im Runbook getrennt, sonst wird ein Endpunktumzug als Neuausstellung erfasst.
Wenn die Triage stockt, trenne die beiden Schichten ausdrücklich: Liefert die Erkennung den erwarteten Endpunkt, und erreicht ein Handshake ihn? Wenn die Erkennung stimmt und Pakete scheitern, liegt das Problem unter dem Overlay. Wenn die Erkennung falsch ist, liegt das Problem in der Map oder der Ankündigung, und die Behebung gehört dorthin.