Nebula static_host_map: die Adresse, die ein Leuchtturm nicht liefern kann

Jeder Leuchtturm kann einem Host von jedem anderen Peer erzählen, außer davon, wo der Leuchtturm selbst liegt. Etwas muss bekannt sein, bevor das Overlay existiert, und Nebula legt dieses Etwas in eine kleine Map. Die Map paart eine Overlay-Identität mit einer Adresse, die im gewöhnlichen Netz funktioniert. Alles, was später gelernt wird, hängt davon ab, dass diese Paarung stimmt.

Zwei Adressen mit zwei Aufgaben

Jeder Nebula-Host besitzt eine Overlay-Adresse, die fest bleibt, während das Gerät zwischen Netzen wechselt. Diese Adresse ist die Identität, die Zertifikate, Firewall-Regeln und Peer-Beziehungen verwenden, und allein routet sie nirgendwohin. Der erreichbare Endpunkt ist etwas anderes: ein Hostname oder eine Adresse im darunterliegenden Netz plus ein UDP-Port, und er ändert sich, sobald die Maschine den Standort wechselt. Die statische Map ist die Verbindung zwischen beiden.

In die Map gehören nur Hosts, die kalt gewählt werden müssen, was meist die Leuchttürme und vielleicht ein Relay bedeutet. Diese Liste kurz zu halten ist ein Designziel, denn jeder manuelle Eintrag wird eine Tatsache, die jemand pflegen muss. Die beiden Adresstypen zu verwechseln ist der übliche Konfigurationsfehler: eine öffentliche Adresse in der Leuchtturm-Liste startet die Erkennung nicht.

Identität gehört dorthin, wo Identität erwartet wird. Erreichbarkeit gehört in die Map.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomie eines Map-Eintrags

Der Schlüssel ist die Overlay-Adresse als Zeichenkette in Anführungszeichen, und der Wert ist eine Liste von Endpunkten, sodass eine Identität mehrere Einstiegspunkte haben kann. Jeder Endpunkt trägt einen Host und einen Port, und der Port muss zu dem passen, worauf die Gegenseite tatsächlich lauscht. Nebulas Standard ist UDP 4242, ein Ausgangspunkt und kein Versprechen für deine Umgebung.

Mehrere Endpunkte sind nützlich, wenn ein Leuchtturm mehr als einen Weg hinein hat, etwa eine öffentliche Adresse und eine private Adresse für Hosts im selben Segment. Der Client probiert sie der Reihe nach, also gehört der zuverlässigste nach vorn. Bei IPv6 kommt die Adresse in eckige Klammern, bevor der Port angehängt wird; ein Fehler dabei erzeugt einen Parserfehler, der auf die falsche Zeile zeigt.

Ein falscher Port erzeugt Schweigen statt eines Fehlers, weil UDP keinen Handshake hat, der ablehnen könnte. Deshalb lohnt es sich, das Eintragsformat gegen die Nebula-Referenz zu static_host_map zu prüfen statt gegen das Gedächtnis. Die Referenz deckt auch Endpunktlisten und das DNS-Aktualisierungsverhalten ab.

Bootstrap muss vor dem Overlay funktionieren

Ein DNS-Name in der Map muss über den Resolver auflösen, den der Host vor jedem Tunnel hat, also den gewöhnlichen Systemresolver. Teste das auf derselben Maschine beim Booten mit gestopptem Overlay. Ein Name, der nur über das eigene DNS des Overlays auflöst, kann das Overlay nicht bootstrappen. Derselbe Test gilt für die Route: Eine Firewall-Regel, die das Overlay erlaubt, aber nicht den ersten UDP-Austausch, blockiert das erste Paket.

Prüfe den Port mit einem UDP-Werkzeug, statt anzunehmen, er sei offen. Bestätige, dass jede Portweiterleitung auf dem Weg auf den richtigen internen Host zeigt und dass ein Rückweg existiert. Löst der Hostname auf mehrere Adressen auf, teste jede einzelne, denn ein Client kann eine Adresse wählen, die du nie geprüft hast.

Statische Einträge werden direkt gewählt und fragen nie einen Leuchtturm. Deshalb sieht ein Ausfall hier wie ein gewöhnlicher Timeout ohne beteiligten Peer aus.

Was nach dem ersten Handshake passiert

Sobald ein Host einen Leuchtturm erreicht, erfährt er ohne weitere manuelle Einträge von Peers und deren erreichbaren Adressen. Hosts, die sich seit der letzten Verbindung bewegt haben, werden über diesen Kanal auffindbar. Das ist der Lohn dafür, die manuelle Map klein zu halten.

Hosts können auch eigene zusätzliche erreichbare Adressen ankündigen, und so hilft ein Peer hinter einer bekannten öffentlichen Adresse anderen, ihn zu finden. Diese Ankündigungen werden gelernt, nicht in die statische Map getippt.

Das Aktualisierungsverhalten zählt bei Endpunkten, die als DNS-Namen geschrieben sind, weil sich eine aufgelöste Adresse ändern kann, während der Prozess weiterläuft. Nebulas Einstellungen steuern, wie diese Abfragen ablaufen, einschließlich des verwendeten Resolvers, also lies sie, statt den Systemstandard anzunehmen. Auf einem Host, dessen Resolver sich ändert, wenn ein Tunnel hochkommt, kann die falsche Einstellung aus einem funktionierenden Bootstrap einen Namen machen, der mitten in der Sitzung nicht mehr auflöst. Die Abfrage an einen stabilen Resolver zu binden ist oft der Unterschied zwischen einem zuverlässigen Overlay und einem mit Aussetzern.

Wenn die Erkennung funktioniert und ein Peer nicht

Sind die Leuchttürme erreichbar und verbinden sich die meisten Peers, ist der Bootstrap nicht das Problem. Das verbleibende Paar findet entweder keinen brauchbaren Weg zueinander oder scheitert oberhalb der Erreichbarkeit. Eine weitere Schreibweise der Leuchtturm-Adresse hinzuzufügen repariert keinen der beiden Fälle.

Prüfe das Paar, bevor du die Map bearbeitest, auf der bereits alles andere beruht. Eine Änderung der Map stört jeden Host, sie ist also das Letzte, was man anfasst, nicht das Erste.

Beginne mit Zertifikaten derselben Autorität, denn ein abgelehnter Handshake kann aus der Ferne wie ein unerreichbarer Peer aussehen. Prüfe dann, ob das Paar einen direkten Weg aufbauen kann und ob ein Relay für Netze konfiguriert ist, die direkten Verkehr ablehnen. Ein Relay fügt einen Hop und eine Abhängigkeit hinzu, aber es ist eine unterstützte Antwort, und den Peer-Weg zu reparieren ist eine andere Aufgabe als die Erkennung zu reparieren.