Nebula rele nastavljen, a neuporabljen: tri nastavitve za preverjanje

Dodali ste gostitelja releja, njegov naslov Nebula zapisali v konfiguracijo, in dva sopotnika se še vedno ne pogovarjata. To se zgodi zato, ker pot prek releja zahteva tri ločene izjave, ki se morajo ujemati, in le ena od njih je na stroju, ki ste ga verjetno urejali. To sem zasledoval dvakrat: enkrat gostitelj posredovanja ni nikoli dobil vloge releja, drugič so bile nastavitve zapisane na napačni strani povezave. Spodnje zaporedje preveri vlogo, oznanilo in dovoljenje v tem vrstnem redu, in vsak korak ima ukaz, ki vam pove, ali naj nadaljujete.

Pred urejanjem konfiguracije preslikajte tri vloge

Nebula vsakemu gostitelju dodeli nalogo, in naloge se ne dedujejo. Lighthouse odgovarja na vprašanja, kot je kje je ta sopotnik, da se gostitelji lahko najdejo. Rele posreduje promet med dvema sopotnikoma, ki nimata delujoče neposredne poti. Navaden gostitelj ne počne ne enega ne drugega. Tri pomembne nastavitve so na treh različnih strojih, zato lahko konfiguracija odjemalca, ki je videti popolna, pusti oba sopotnika čakati.

# 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

En sam simptom loči dva razreda okvare. Če se oba sopotnika navajata drug drugega in dnevnik kaže poskuse rokovanja, ki se nikoli ne končajo, odkrivanje deluje, podatkovno pot pa blokira NAT ali požarni zid. Če sopotnik sploh ne izve naslova drugega, je težava v lighthouseu ali v njegovem statičnem zemljevidu gostiteljev, in nastavitve releja tega ne morejo popraviti.

Preden spremenite karkoli drugega, potrdite, katero konfiguracijo je vsak gostitelj dejansko naložil. Enota, ki bere drugačno pot od datoteke, ki ste jo uredili, je pogost in neroden vzrok za »sprememba ni naredila ničesar«:

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

Vrstica različice je pomembna v mešani floti. Ravnanje z releji, vedenje prebadanja in sprejeti konfiguracijski ključi niso enaki med izdajami, zato ne predpostavljajte, da starejša gradnja razume razdelek, za katerega ni bila napisana. Poravnajte gostitelje na isto manjšo serijo, nato zaženite nebula -test -config /etc/nebula/config.yml na vsakem gostitelju in primerjajte izhod, preden začnete iskati napake v transportu, ki ga koda ne izvaja.

Omogočite vlogo posredovanja na gostitelju releja

Vloga releja je ena sama zastavica na gostitelju posredovanja in je ločena od tega, da je lighthouse. Gostitelj z omogočenim odkrivanjem in onemogočenim posredovanjem prek releja je še vedno le storitev odkrivanja. Na releju:

relay:
  am_relay: true

Ta zastavica izraža namero; ne ustvarja dosegljivosti. Rele mora biti dosegljiv z obeh sopotnikov, kar v praksi pomeni javni naslov, dohodni UDP na vratih Nebula, odprt v požarnem zidu gostitelja in v kateri koli varnostni skupini oblaka, in brez dvojnega NAT pred njim. Preverite vtičnico, ki posluša, in nato opazujte, ali prihajajo paketi sopotnika:

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

Dve omejitvi prihranita čas pozneje. Do releja ni mogoče priti prek drugega releja, zato veriga imen relejev v konfiguraciji ne nadomesti uporabne poti do gostitelja posredovanja. In rele posreduje pakete; ne podeljuje dovoljenja, o tem, ali je posredovani tok dovoljen, še vedno odločajo lastna dohodna pravila cilja. Vloga in njene zahteve so opisane v dokumentaciji o konfiguraciji releja.

Rele oznanite s cilja, ne z odjemalca

To je obrat, ki požre največ ur. Seznam relejev pripada gostitelju, ki ga poskušate doseči, ker drugim sopotnikom pove, kateri releji se smejo uporabiti za dosego tega gostitelja. Če ga postavite na odjemalca, ki povezavo začne, to ne naredi ničesar za smer, ki jo odjemalec potrebuje:

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

Sopotniki ta seznam sporočajo skupaj s svojimi naslovi, ko se prijavijo pri lighthouseu, zato se oznanilo širi z odkrivanjem in ne z neposredno izmenjavo. Če cilj ne doseže nobenega lighthousea, se njegov seznam relejev nikoli ne razširi in pravilno nastavljen rele ostane brez dela. Ta okvara je videti natanko kot pokvarjen rele in ni.

Cilju dajte zagonsko pot v istem koraku. Statični zemljevid gostiteljev veže naslov Nebula na javno končno točko, da ima prvo rokovanje kam iti, in potrebuje vnos za rele, če naj cilj sprejema posredovani promet z gostiteljev, ki jih ne doseže neposredno:

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

Dovolite povezujočemu sopotniku uporabo releja

Začetna stran potrebuje lastno dovoljenje. relay.use_relays je privzeto vklopljen, zato je primer, ki se ga je vredno iskati, izrecni false, pogosto kopiran iz predloge, napisane pred obstojem funkcije releja, ali puščen od prejšnjega poskusa vsilitve neposrednih poti:

relay:
  use_relays: true

Dovoljenje na tej strani ni edina vrata. Dohodna pravila cilja še vedno veljajo za posredovani paket, in vir, s katerim se primerjajo, je identiteta znotraj tunela in ne naslov samega releja. Ko se posredovano rokovanje konča in aplikacija še vedno odpove, preberite v dnevniku cilja, kateri vir si je zabeležil, preden prepišete pravilo.

Nastavitve prehajanja NAT delujejo skupaj z vsem tem. punchy.punch pomaga dvema sopotnikoma odpreti neposredno pot, in ko uspe, ni posredovanega prometa za opazovanje; to je uspeh, ne manjkajoč rele. Par, ki deluje občasno, običajno pomeni, da prebadanje uspe le včasih, zato ta par preizkusite večkrat, namesto da bi iz enega poskusa naredili sklep.

Preverite s parom, ki je odpovedal, in nato znova naložite

Preizkusite tista dva gostitelja, ki sta res odpovedala, z aplikacijo, ki jo potrebujeta. Uspešen ping z vaše delovne postaje do storitve samega releja ne dokaže ničesar o posredovanju med dvema drugima sopotnikoma, in to je najpogostejši lažni pozitiv v celotnem postopku.

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

Znova naložite, namesto da znova zaženete, in potrdite, da je tekoči proces prevzel datoteko, ki ste jo uredili. Ponovni zagon pretrga vsak tunel in naredi naslednji preizkus težje berljiv, medtem ko SIGHUP obdrži proces in mu omogoči, da znova prebere konfiguracijo:

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

systemctl reload deluje le, kadar lokalna enota definira ExecReload, in enota, ki se dobavlja s projektom, tega ne počne, zato je systemctl kill -s HUP korak, ki uspe pri standardni namestitvi. Po ponovnem nalaganju preberite v dnevniku pot do konfiguracije, ki jo je proces odprl, da boste vedeli, da je bila prebrana nova datoteka in ne tista, za katero ste domnevali, da je naložena.

Nastavitve releja in prebadanje NAT delujeta oba na pot; nobeno ne deluje na identiteto. Če par še vedno odpove pri rokovanju, ko so am_relay, relays in use_relays potrjeni v tekoči konfiguraciji, preverite, ali oba gostitelja predložita potrdila, izdana za imena, s katerimi sta nastavljena, in ali je CA na obeh straneh enak. Konfiguracijo potrdil in požarnega zidu držite nespremenjeno, medtem ko spreminjate eno transportno nastavitev naenkrat, ker sprememba potrdila in sprememba releja v istem preizkusu ne povesta, katera od njiju je premaknila rokovanje. Neusklajenost imena ali CA odpove na istem mestu kot rele, ki ni bil nikoli najden, zato ta protipreveritev sodi v isti korak.

Nato potrdite, da je vsaka izjava v datoteki, ki ji pripada:

• am_relay: true na gostitelju posredovanja, in ta gostitelj dosegljiv prek UDP z obeh strani.
• relays: z naslovom Nebula tega gostitelja na cilju.
• use_relays: true na sopotniku, ki povezavo začne.
• Dohodna pravila na cilju, ki tudi po spremembi poti dovolijo dejanski vir.