Nebula-Relay konfiguriert, aber ungenutzt: drei Einstellungen zum Prüfen

Sie haben einen Relay-Host hinzugefügt, seine Nebula-Adresse in eine Konfiguration eingetragen, und die beiden Peers sprechen trotzdem nicht miteinander. Das liegt daran, dass ein Relay-Pfad drei getrennte Aussagen braucht, die übereinstimmen müssen, und nur eine davon steht auf der Maschine, die Sie wahrscheinlich bearbeitet haben. Ich habe das zweimal nachverfolgt: einmal hatte der weiterleitende Host nie die Relay-Rolle bekommen, einmal waren die Einstellungen auf der falschen Seite der Verbindung geschrieben. Die folgende Reihenfolge prüft Rolle, Ankündigung und Berechtigung in genau dieser Ordnung, und jeder Schritt hat einen Befehl, der Ihnen sagt, ob Sie weitermachen sollen.

Ordnen Sie die drei Rollen zu, bevor Sie eine Konfiguration bearbeiten

Nebula gibt jedem Host eine Aufgabe, und diese Aufgaben werden nicht vererbt. Ein Lighthouse beantwortet die Frage, wo ein bestimmter Peer zu finden ist, damit Hosts einander finden. Ein Relay leitet Datenverkehr zwischen zwei Peers weiter, die keinen funktionierenden direkten Pfad haben. Ein gewöhnlicher Host macht weder das eine noch das andere. Die drei Einstellungen, auf die es ankommt, liegen auf drei verschiedenen Maschinen, und deshalb kann eine Client-Konfiguration, die vollständig aussieht, beide Peers warten lassen.

# 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

Ein einziges Symptom trennt die beiden Fehlerklassen. Wenn beide Peers einander auflisten und das Protokoll Handshake-Versuche zeigt, die nie abgeschlossen werden, funktioniert die Erkennung, und der Datenpfad wird von NAT oder einer Firewall blockiert. Wenn ein Peer die Adresse des anderen überhaupt nicht erfährt, liegt das Problem beim Lighthouse oder in dessen statischer Host-Map, und Relay-Einstellungen können das nicht reparieren.

Prüfen Sie, welche Konfiguration jeder Host tatsächlich geladen hat, bevor Sie irgendetwas anderes ändern. Eine Unit, die einen anderen Pfad liest als die von Ihnen bearbeitete Datei, ist eine häufige und peinliche Ursache dafür, dass „die Änderung nichts bewirkt hat“:

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

Die Versionszeile zählt in einem gemischten Bestand. Relay-Behandlung, Punching-Verhalten und akzeptierte Konfigurationsschlüssel sind nicht über alle Releases hinweg identisch, gehen Sie also nicht davon aus, dass ein älterer Build einen Abschnitt versteht, für den er nicht geschrieben wurde. Bringen Sie die Hosts auf dieselbe Minor-Reihe, führen Sie dann nebula -test -config /etc/nebula/config.yml auf jedem Host aus und vergleichen Sie die Ausgabe, bevor Sie einen Transport debuggen, den der Code nicht implementiert.

Aktivieren Sie die Weiterleitungsrolle auf dem Relay-Host

Die Relay-Rolle ist ein einzelnes Flag auf dem weiterleitenden Host, und sie ist unabhängig davon, ob dieser Host ein Lighthouse ist. Ein Host mit aktivierter Erkennung und deaktivierter Relay-Weiterleitung bleibt nur ein Discovery-Dienst. Auf dem Relay:

relay:
  am_relay: true

Dieses Flag erklärt eine Absicht; es schafft keine Erreichbarkeit. Ein Relay muss von beiden Peers aus erreichbar sein, was in der Praxis eine öffentliche Adresse bedeutet, eingehendes UDP auf dem Nebula-Port, geöffnet in der Host-Firewall und in jeder Cloud-Sicherheitsgruppe, und kein doppeltes NAT davor. Prüfen Sie den lauschenden Socket und beobachten Sie dann, ob die Pakete des Peers ankommen:

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

Zwei Grenzen sparen später Zeit. Ein Relay ist nicht über ein anderes Relay erreichbar, eine Kette von Relay-Namen in einer Konfiguration ersetzt also keinen brauchbaren Pfad zum weiterleitenden Host. Und ein Relay leitet Pakete weiter; es erteilt keine Berechtigung, die eingehenden Regeln des Ziels entscheiden weiterhin, ob der weitergeleitete Datenstrom erlaubt ist. Die Rolle und ihre Anforderungen stehen in der Relay-Konfigurationsdokumentation.

Kündigen Sie das Relay vom Ziel aus an, nicht vom Client

Das ist die Umkehrung, die die meisten Stunden frisst. Die Relay-Liste gehört auf den Host, den Sie erreichen wollen, denn sie teilt anderen Peers mit, welche Relays zur Erreichbarkeit dieses Hosts verwendet werden dürfen. Sie auf den Client zu setzen, der die Verbindung aufbaut, bringt für die Richtung, die der Client braucht, nichts:

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

Peers melden diese Liste zusammen mit ihren Adressen, wenn sie sich beim Lighthouse melden, die Ankündigung verbreitet sich also über die Erkennung statt über einen direkten Austausch. Wenn das Ziel kein Lighthouse erreicht, verbreitet sich seine Relay-Liste nie, und ein korrekt konfiguriertes Relay bleibt untätig. Dieser Fehler sieht genau wie ein defektes Relay aus und ist keines.

Geben Sie dem Ziel im selben Durchgang einen Bootstrap-Pfad. Die statische Host-Map verbindet eine Nebula-Adresse mit einem öffentlichen Endpunkt, damit der erste Handshake ein Ziel hat, und sie braucht einen Eintrag für das Relay, wenn das Ziel weitergeleiteten Verkehr von Hosts annehmen soll, die es nicht direkt erreicht:

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

Erlauben Sie dem verbindenden Peer die Nutzung des Relays

Die ausgehende Seite braucht ihre eigene Berechtigung. relay.use_relays ist standardmäßig aktiv, gesucht ist also der Fall eines ausdrücklichen false, oft aus einer Vorlage übernommen, die vor der Relay-Funktion entstand, oder hinterlassen von einem früheren Versuch, direkte Pfade zu erzwingen:

relay:
  use_relays: true

Die Berechtigung auf dieser Seite ist nicht das einzige Tor. Die eingehenden Regeln des Ziels gelten weiterhin für das weitergeleitete Paket, und die Quelle, mit der sie abgeglichen wird, ist die Identität im Tunnel und nicht die Adresse des Relays selbst. Wenn der weitergeleitete Handshake abgeschlossen ist und die Anwendung trotzdem scheitert, sehen Sie im Protokoll des Ziels nach, welche Quelle es erfasst hat, bevor Sie eine Regel umschreiben.

NAT-Traversal-Einstellungen wirken hier mit alldem zusammen. punchy.punch hilft zwei Peers, einen direkten Pfad zu öffnen, und wenn das gelingt, gibt es keinen Relay-Verkehr zu beobachten; das ist ein Erfolg und kein fehlendes Relay. Ein Paar, das zeitweise funktioniert, bedeutet meist, dass das Punching nur manchmal erfolgreich ist, testen Sie dieses Paar also mehrmals, statt aus einem einzigen Versuch einen Schluss zu ziehen.

Prüfen Sie mit dem Paar, das gescheitert ist, und laden Sie dann neu

Testen Sie die zwei Hosts, die tatsächlich gescheitert sind, mit der Anwendung, die sie brauchen. Ein erfolgreicher Ping von Ihrer Workstation zum Dienst des Relays selbst beweist nichts über die Weiterleitung zwischen zwei anderen Peers, und das ist der häufigste Fehlalarm in diesem ganzen Verfahren.

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

Laden Sie neu, statt neu zu starten, und prüfen Sie, ob der laufende Prozess die von Ihnen bearbeitete Datei übernommen hat. Ein Neustart reißt jeden Tunnel ab und macht den nächsten Test schwerer lesbar, während ein SIGHUP den Prozess behält und ihn die Konfiguration neu einlesen lässt:

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

systemctl reload funktioniert nur, wenn die lokale Unit ExecReload definiert, und die mit dem Projekt ausgelieferte Unit tut das nicht, systemctl kill -s HUP ist also der Schritt, der bei einer Standardinstallation gelingt. Lesen Sie nach dem Neuladen das Journal zum Konfigurationspfad, den der Prozess geöffnet hat, damit Sie wissen, dass die neue Datei gelesen wurde und nicht die, von der Sie annahmen, sie sei geladen.

Relay-Einstellungen und NAT-Punching wirken beide auf den Pfad; keine von beiden wirkt auf die Identität. Wenn das Paar seinen Handshake weiterhin nicht schafft, obwohl am_relay, relays und use_relays in der laufenden Konfiguration bestätigt sind, prüfen Sie, ob beide Hosts Zertifikate vorlegen, die für die konfigurierten Namen ausgestellt wurden, und ob die CA auf beiden Seiten dieselbe ist. Halten Sie Zertifikats- und Firewall-Konfiguration fest, während Sie jeweils eine Transporteinstellung ändern, denn eine Zertifikatsänderung und eine Relay-Änderung im selben Test sagen Ihnen nichts darüber, welche von beiden den Handshake bewegt hat. Eine Namens- oder CA-Abweichung scheitert an derselben Stelle wie ein Relay, das nie gefunden wurde, und deshalb gehört diese Gegenprobe in denselben Durchgang.

Bestätigen Sie dann, dass jede Aussage in der Datei steht, zu der sie gehört:

• am_relay: true auf dem weiterleitenden Host, und dieser Host von beiden Seiten über UDP erreichbar.
• relays: mit der Nebula-Adresse dieses Hosts auf dem Ziel.
• use_relays: true auf dem Peer, der die Verbindung aufbaut.
• Eingehende Regeln auf dem Ziel, die die echte Quelle auch nach dem Pfadwechsel noch zulassen.