Nebula-Relay konfiguréiert, awer onbenotzt: dräi Astellungen zum Iwwerpréiwen

Du hues en Relayhost derbäigesat, seng Nebula-Adress an eng Konfiguratioun agedroen, an déi zwee Peere schwätze weiderhin net mateneen. Dat kënnt dohier, datt e Relaywee dräi getrennt Deklaratiounen nodig huet, déi sech eens musse ginn, an nëmmen eng dovu steet op der Maschinn, déi s du wahrscheinlech geännert hues. Ech sinn dat zweemol duerchgaang: eng Kéier hat den duerchleedenden Host ni d’Relayroll kritt, an eng Kéier waren d’Astellungen op der falscher Säit vun der Verbindung ageschriwwen. D’Reiefolleg hei drënner préift d’Roll, d’Ukënnegung an d’Erlaabnes an där Uerdnung, an all Schrëtt huet eng Kommando, déi dir seet, ob s du weidermaache solls.

Kaart déi dräi Rolle virum s du eng Konfiguratioun änderst

Nebula gëtt all Host eng Aufgab, an dës Aufgabe ginn net geierft. E Lighthouse beäntwert Froen wéi wou ass dëse Peer, sou datt Hosten sech fanne kënnen. E Relay leet Verkéier tëschent zwee Peere weider, déi keen funktionéierende direkte Wee hunn. En normale Host mécht keent vun deenen zwee. Déi dräi Astellungen déi zielen, leien op dräi verschiddene Maschinnen, an dofir kann eng Clientkonfiguratioun déi komplett ausgesäit déi zwee Peeren waarde loossen.

# 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

Een eenzege Symptom trennt déi zwou Fehlerklassen. Wann déi zwee Peeren sech géigesäiteg oplëschten an de Log Handshakeversich weist déi ni färdeg ginn, funktionéiert d’Entdeckung an de Datenwee gëtt vun NAT oder vun enger Firewall blockéiert. Wann e Peer d’Adress vum anere guer net gewuer gëtt, läit de Problem beim Lighthouse oder an senger statescher Hostmap, an Astellunge vum Relay kënnen dat net reparéieren.

Bestäteg wéi eng Konfiguratioun all Host tatsächlech gelueden huet, ier du eppes anescht änderst. Eng Unit déi en anere Wee liest wéi d’Datei déi s du geännert hues, ass eng heefeg an onangenehm Ursaach dofir datt „d’Ännerung näischt gemaach huet“:

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

D’Versiounslinn zielt an enger gemëschter Flotte. Relaybehandlung, Punchverhalen an akzeptéiert Konfiguratiounsschlësselen sinn net iwwer all Release identesch, geh also net dovun aus datt en eelere Build eng Sektioun versteet fir déi en net geschriwwe gouf. Bréng d’Hosten op déi selwecht Minor-Rei, fuer dann nebula -test -config /etc/nebula/config.yml op all Host aus a vergläich de Output, ier du en Transport debuggs deen de Code net implementéiert.

Aktivéier d’Duerchleedungsroll um Relayhost

D’Relayroll ass ee Flag um duerchleedenden Host, an se ass onofhängeg dovun ob dësen Host e Lighthouse ass. En Host mat aktivéierter Entdeckung an desaktivéierter Relayduerchleedung bleift just en Entdeckungsservice. Um Relay:

relay:
  am_relay: true

Dee Flag erkläert eng Absicht; en erschaaft keng Erreechbarkeet. E Relay muss vun deenen zwee Peeren aus erreechbar sinn, wat an der Praxis eng ëffentlech Adress bedeit, akommes UDP um Nebula-Port op an der Hostfirewall an an all Cloud-Sécherheetsgrupp, an keen duebelen NAT dovirun. Préif de lauschenden Socket a kuck dann ob d’Pakete vum Peer ukënnen:

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

Zwou Grenze spueren spéider Zäit. Een Relay ass net iwwer en aneren Relay erreechbar, also ersetzt eng Kette vu Relaynimm an enger Konfiguratioun keen brauchbare Wee zum duerchleedenden Host. An e Relay leet Pakete weider; en erdeelt keng Erlaabnes, d’akommes Regelen vum Zil entscheeden weider ob de weidergeleet Stroum erlaabt ass. D’Roll an hir Ufuerderunge stinn an der Dokumentatioun iwwer d’Relaykonfiguratioun.

Kënneg de Relay vum Zil aus un, net vum Client

Dat ass d’Ëmkéierung déi déi meeschten Stonnen ësst. D’Relaylëscht gehéiert op den Host deen s du erreeche wëlls, well se anere Peeren seet wéi eng Relays benotzt däerfe ginn fir dësen Host z’erreechen. Se op de Client ze setzen deen d’Verbindung opbaut, bréngt näischt fir d’Richtung déi de Client brauch:

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

Peeren mellen déi Lëscht zesumme mat hiren Adressen, wann se sech beim Lighthouse mellen, also verbreet sech d’Ukënnegung iwwer d’Entdeckung an net iwwer en direkten Austausch. Wann d’Zil keen Lighthouse erreecht, verbreet seng Relaylëscht sech ni an e korrekt konfiguréierte Relay bleift idle. Dee Fehler gesäit genee aus wéi en defekte Relay an ass keen.

Gëff dem Zil en Bootstrap-Wee an der selwechter Ronn. D’statesch Hostmap verbënnt eng Nebula-Adress mat engem ëffentlechen Endpunkt, sou datt den éischten Handshake eng Plaz huet wou en higeet, an se brauch en Agang fir de Relay wann d’Zil weidergeleet Verkéier vun Hosten acceptéiere soll déi et net direkt erreecht:

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

Loos de verbindende Peer de Relay benotzen

Déi initiéierend Säit brauch hir eegen Erlaabnes. relay.use_relays ass standardméisseg un, also de Fall deen et sech lount ze sichen ass eng explizit false, dacks aus enger Schabloun kopéiert déi geschriwwe gouf ier d’Relayfunktioun existéiert huet oder hannerlooss vun engem fréiere Versuch direkt Weeër ze forcéieren:

relay:
  use_relays: true

D’Erlaabnes op dëser Säit ass net dat eenzegt Paart. D’akommes Regelen vum Zil gëllen weider fir de weidergeleet Paket, an d’Quell mat där se verglach gëtt ass d’Identitéit am Tunnel an net d’Adress vum Relay selwer. Wann den weidergeleeten Handshake färdeg ass an d’Applikatioun nach ëmmer feelt, lies de Log vum Zil fir d’Quell déi et opgeholl huet, ier du eng Regel ëmschreifs.

NAT-Traversalsastellungen wierken hei mat allem zesummen. punchy.punch hëlleft zwee Peeren en direkte Wee opzemaachen, an wann dat geléngt gëtt et keen Relayverkéier ze gesinn; dat ass Erfolleg, keen feelenden Relay. E Paar dat mat Ënnerbriechungen funktionéiert bedeit meeschtens datt de Punch nëmmen heiansdo geléngt, test dëst Paar also méi Mol amplaz aus engem eenzege Versuch eng Konklusioun ze zéien.

Verifizéier mam Paar dat gefeelt huet a lued dann nei

Test déi zwee Hosten déi tatsächlech gefeelt hunn, mat der Applikatioun déi se brauchen. En erfollegräiche Ping vun denger Aarbechtsstatioun op de Service vum Relay selwer beweise näischt iwwer d’Weiderleedung tëschent zwee aneren Peeren, an et ass de heefegste falsche positiven an dëser ganzer Prozedur.

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

Lued nei amplaz nei ze starten, a bestäteg datt de lafende Prozess d’Datei opgeholl huet déi s du geännert hues. En Neistart räisst all Tunnel of a mécht den nächsten Test schwéierer ze liesen, wärend en SIGHUP de Prozess behält an en d’Konfiguratioun nei liest:

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

systemctl reload funktionéiert nëmmen wann déi lokal Unit ExecReload definéiert, an d’Unit déi mam Projet ausgeliwwert gëtt mécht dat net, also ass systemctl kill -s HUP de Schrëtt deen op enger Standardinstallatioun geléngt. Lies no dem Neilueden de Journal fir de Konfiguratiounswee deen de Prozess opgemaach huet, sou datt s du weess datt déi nei Datei gelies gouf an net déi déi s du ugeholl hues wier gelueden.

Relayastellungen an NAT-Punching wierken allebéid op den Wee; keen vun deenen zwee wierkt op d’Identitéit. Wann d’Paar säin Handshake nach ëmmer feelt nodeems am_relay, relays an use_relays an der lafender Konfiguratioun bestätegt sinn, préif ob béid Hosten Zertifikater weisen déi fir d’Nimm ausgestallt goufen mat deenen se konfiguréiert sinn an ob d’CA op béide Säiten déiselwecht ass. Halt d’Zertifikats- a Firewallkonfiguratioun fest wärend s du eng Transportastellung op eemol änderst, well eng Zertifikatsännerung an eng Relayännerung am selwechten Test soen dir näischt driwwer wéi eng vun deenen zwee den Handshake geréckelt huet. Eng Numm- oder CA-Ofwäichung feelt op déiselwechter Plaz wéi en Relay deen ni fonnt gouf, an dofir gehéiert dës Géigenpréifung an déiselwecht Ronn.

Bestäteg duerno datt all Deklaratioun an der Datei steet wou se higehéiert:

• am_relay: true um duerchleedenden Host, an dësen Host vun béide Säiten iwwer UDP erreechbar.
• relays: mat der Nebula-Adress vun dësem Host um Zil.
• use_relays: true um Peer deen d’Verbindung opbaut.
• Akommes Regelen um Zil déi déi richteg Quell och no der Weeännerung nach erlaaben.