Preposielací uzol Nebula nakonfigurovaný, ale nevyužitý: tri nastavenia na kontrolu

Pridali ste preposielací host, zapísali jeho adresu Nebula do konfigurácie a dve protistrany spolu stále nekomunikujú. Deje sa to preto, lebo cesta cez preposielací uzol potrebuje tri samostatné vyhlásenia, ktoré sa musia zhodovať, a iba jedno z nich je na stroji, ktorý ste pravdepodobne upravovali. Sledoval som to dvakrát: raz preposielací host nikdy nedostal rolu preposielacieho uzla a raz boli nastavenia zapísané na nesprávnej strane spojenia. Nasledujúca postupnosť kontroluje rolu, ohlásenie a oprávnenie v tomto poradí a každý krok má príkaz, ktorý vám povie, či pokračovať.

Zmapujte tri roly, kým upravíte konfiguráciu

Nebula dáva každému hostu úlohu a úlohy sa nedededia. Lighthouse odpovedá na otázky typu kde je táto protistrana, aby sa hosty navzájom našli. Preposielací uzol prenáša prevádzku medzi dvoma protistranami, ktoré nemajú funkčnú priamu cestu. Bežný host nerobí ani jedno. Tri dôležité nastavenia sídlia na troch rôznych strojoch, a preto konfigurácia klienta, ktorá vyzerá úplne, môže nechať obe protistrany čakať.

# 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

Jeden príznak oddeľuje dve triedy zlyhania. Ak sa obe protistrany navzájom uvádzajú a log ukazuje pokusy o handshake, ktoré sa nikdy neskončia, zisťovanie funguje a dátovú cestu blokuje NAT alebo firewall. Ak sa protistrana vôbec nedozvie adresu druhej, problém je v lighthouse alebo v jeho statickej mape hostov a nastavenia preposielacieho uzla to nespravia.

Potvrďte, ktorú konfiguráciu každý host skutočne načítal, kým zmeníte čokoľvek iné. Unit, ktorý číta inú cestu ako súbor, ktorý ste upravili, je častou a trápnou príčinou toho, že „zmena nič neurobila“:

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

Riadok verzie má význam v zmiešanej flotile. Spracovanie preposielacích uzlov, správanie punchovania a prijímané konfiguračné kľúče nie sú naprieč vydaniami totožné, takže nepredpokladajte, že starší build rozumie sekcii, pre ktorú nebol napísaný. Zosúlaďte hosty na rovnaký minor rad, potom spustite nebula -test -config /etc/nebula/config.yml na každom hoste a porovnajte výstup, kým začnete ladiť transport, ktorý kód neimplementuje.

Zapnite rolu preposielania na preposielacom hoste

Rola preposielacieho uzla je jediný príznak na preposielacom hoste a je oddelená od toho byť lighthouse. Host so zapnutým zisťovaním a vypnutým preposielaním cez uzol je stále len služba zisťovania. Na preposielacom uzle:

relay:
  am_relay: true

Tento príznak deklaruje zámer; nevytvára dosiahnuteľnosť. Preposielací uzol musí byť dosiahnuteľný z oboch protistrán, čo v praxi znamená verejnú adresu, prichádzajúce UDP na porte Nebula otvorenom vo firewalle hostu a v akejkoľvek cloudovej bezpečnostnej skupine a žiadny dvojitý NAT pred ním. Skontrolujte počúvajúci socket a potom sledujte, či prichádzajú pakety protistrany:

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

Dve obmedzenia šetria čas neskôr. K preposielaciemu uzlu sa nedostanete cez iný uzol, takže reťaz mien uzlov v konfigurácii nenahrádza použiteľnú cestu k preposielaciemu hostu. A uzol preposiela pakety; neudeľuje oprávnenie, o tom, či je preposielaný tok povolený, rozhodujú ďalej vlastné prichádzajúce pravidlá cieľa. Rola a jej požiadavky sú v dokumentácii ku konfigurácii preposielacieho uzla.

Ohláste preposielací uzol z cieľa, nie z klienta

To je obrátenie, ktoré spotrebuje najviac hodín. Zoznam uzlov patrí hostu, ku ktorému sa snažíte dostať, pretože ostatným protistranám hovorí, ktoré uzly možno na dosiahnutie tohto hostu použiť. Umiestniť ho na klienta, ktorý spojenie začína, nič nerobí pre smer, ktorý klient potrebuje:

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

Protistrany hlásia tento zoznam spolu so svojimi adresami, keď sa hlásia v lighthouse, takže ohlásenie sa šíri zisťovaním a nie priamou výmenou. Ak cieľ nedosiahne žiadny lighthouse, jeho zoznam uzlov sa nikdy nerozšíri a správne nastavený uzol zostane nečinný. Toto zlyhanie vyzerá presne ako pokazený uzol a nie je ním.

Dajte cieľu štartovaciu cestu v rovnakom kroku. Statická mapa hostov viaže adresu Nebula k verejnému koncovému bodu, aby mal prvý handshake kam ísť, a potrebuje záznam pre uzol, ak má cieľ prijímať preposielanú prevádzku od hostov, ku ktorým sa nedostane priamo:

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

Nechajte pripájajúcu sa protistranu použiť uzol

Zahajujúca strana potrebuje vlastné oprávnenie. relay.use_relays je v predvolenom stave zapnuté, takže prípadom, ktorý stojí za hľadanie, je výslovné false, často skopírované zo šablóny napísanej pred vznikom funkcie preposielania alebo ponechané skorším pokusom vynútiť priame cesty:

relay:
  use_relays: true

Oprávnenie na tejto strane nie je jediná brána. Prichádzajúce pravidlá cieľa platia aj pre preposielaný paket a zdrojom, s ktorým sa porovnávajú, je identita vnútri tunela, nie adresa samotného uzla. Keď preposielaný handshake skončí a aplikácia napriek tomu zlyháva, prečítajte v logu cieľa, aký zdroj si poznamenal, kým prepíšete pravidlo.

Nastavenia priechodu NAT s tým všetkým spolupôsobia. punchy.punch pomáha dvom protistranám otvoriť priamu cestu, a keď sa to podarí, nie je pozorovateľná žiadna prevádzka cez uzol; to je úspech, nie chýbajúci uzol. Pár, ktorý funguje prerušovane, zvyčajne znamená, že punchovanie občas vyjde, takže tento pár testujte niekoľkokrát, namiesto toho, aby ste z jedného pokusu robili záver.

Overte s párom, ktorý zlyhal, a potom znova načítajte

Testujte tie dva hosty, ktoré skutočne zlyhali, s aplikáciou, ktorú potrebujú. Úspešný ping z vašej pracovnej stanice na službu samotného uzla nič nedokazuje o prenose medzi dvoma inými protistranami a je to najčastejší falošný pozitív v celom tomto postupe.

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

Načítajte znova namiesto reštartu a potvrďte, že bežiaci proces prevzal súbor, ktorý ste upravili. Reštart strhne každý tunel a robí ďalší test horšie čitateľným, zatiaľ čo SIGHUP proces zachová a nechá ho znova načítať konfiguráciu:

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

systemctl reload funguje len vtedy, keď miestny unit definuje ExecReload, a unit dodávaný s projektom to nerobí, takže systemctl kill -s HUP je krok, ktorý na štandardnej inštalácii vyjde. Po opätovnom načítaní si prečítajte v journali cestu ku konfigurácii, ktorú proces otvoril, aby ste vedeli, že sa načítal nový súbor a nie ten, ktorý ste považovali za načítaný.

Nastavenia uzla a punchovanie NAT pôsobia obe na cestu; ani jedno nepôsobí na identitu. Ak pár stále zlyháva v handshake, keď sú am_relay, relays a use_relays potvrdené v bežiacej konfigurácii, skontrolujte, či oba hosty predkladajú certifikáty vydané pre mená, s ktorými sú nastavené, a či je CA na oboch stranách rovnaká. Držte konfiguráciu certifikátov a firewallu nezmenenú, kým meníte jedno transportné nastavenie po druhom, pretože zmena certifikátu a zmena uzla v tom istom teste nič nehovoria o tom, ktorá z nich posunula handshake. Nezhoda mena alebo CA zlyháva na rovnakom mieste ako uzol, ktorý sa nikdy nenašiel, a preto táto protikontrola patrí do rovnakého kroku.

Potom potvrďte, že každé vyhlásenie je v súbore, kam patrí:

• am_relay: true na preposielacom hoste a tento host dosiahnuteľný cez UDP z oboch strán.
• relays: s adresou Nebula tohto hostu na cieli.
• use_relays: true na protistrane, ktorá spojenie začína.
• Prichádzajúce pravidlá na cieli, ktoré aj po zmene cesty povoľujú skutočný zdroj.