Nebula relės serveris sukonfigūruotas, bet nenaudojamas: trys nustatymai, kuriuos reikia patikrinti

Pridėjote relės serverį, įrašėte jo Nebula adresą į konfigūraciją, o du partneriai vis tiek nesusikalba. Taip nutinka todėl, kad maršrutui per relę reikia trijų atskirų teiginių, kurie turi sutapti, ir tik vienas iš jų yra mašinoje, kurią tikriausiai redagavote. Sekiau tai du kartus: vieną kartą perdavimo serveriui niekada nebuvo suteiktas relės vaidmuo, kitą kartą nustatymai buvo įrašyti neteisingoje ryšio pusėje. Toliau pateikta seka tikrina vaidmenį, paskelbimą ir leidimą būtent tokia tvarka, ir kiekvienas žingsnis turi komandą, kuri pasako, ar tęsti.

Susiekite tris vaidmenis prieš redaguodami konfigūraciją

Nebula kiekvienam serveriui duoda užduotį, o užduotys nepaveldimos. Lighthouse atsako į klausimus, pavyzdžiui, kur yra šis partneris, kad serveriai galėtų rasti vienas kitą. Relė persiunčia srautą tarp dviejų partnerių, kurie neturi veikiančio tiesioginio maršruto. Paprastas serveris nedaro nei vieno, nei kito. Trys svarbūs nustatymai yra trijose skirtingose mašinose, todėl kliento konfigūracija, kuri atrodo išsami, gali palikti abu partnerius laukti.

# 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

Vienas simptomas atskiria dvi gedimų klases. Jei abu partneriai vardija vienas kitą ir žurnale matomi rankos paspaudimo bandymai, kurie niekada nepasibaigia, aptikimas veikia, o duomenų kelią blokuoja NAT arba ugniasienė. Jei partneris visiškai nesužino kito adreso, problema yra lighthouse arba jo statiniame serverių žemėlapyje, ir relės nustatymai to nepataisys.

Prieš keisdami ką nors kita, patvirtinkite, kurią konfigūraciją kiekvienas serveris iš tikrųjų įkėlė. Unit, kuris skaito kitą kelią nei jūsų redaguotas failas, yra dažna ir nemaloni priežastis, kodėl „pakeitimas nieko nepadarė”:

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

Versijos eilutė svarbi mišriame parke. Relių apdorojimas, punch elgsena ir priimami konfigūracijos raktai nėra vienodi tarp leidimų, todėl nedarykite prielaidos, kad senesnis build supranta skyrių, kuriam jis nebuvo rašytas. Sulygiuokite serverius į tą pačią minor seriją, tada paleiskite nebula -test -config /etc/nebula/config.yml kiekviename serveryje ir palyginkite išvestį, prieš pradėdami derinti transportą, kurio kodas neįgyvendina.

Įjunkite persiuntimo vaidmenį relės serveryje

Relės vaidmuo yra viena vėliavėlė perdavimo serveryje ir ji atskirta nuo to, kad serveris yra lighthouse. Serveris su įjungtu aptikimu ir išjungtu persiuntimu per relę vis dar yra tik aptikimo paslauga. Relėje:

relay:
  am_relay: true

Ši vėliavėlė deklaruoja ketinimą; ji nesukuria pasiekiamumo. Relė turi būti pasiekiama iš abiejų partnerių, o tai praktiškai reiškia viešą adresą, įeinantį UDP per Nebula prievadą, atidarytą serverio ugniasienėje ir bet kurioje debesijos saugos grupėje, ir jokio dvigubo NAT priešais. Patikrinkite klausančią lizdinę, tada stebėkite, ar ateina partnerio paketai:

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

Dvi ribos vėliau sutaupo laiko. Į relę negalima patekti per kitą relę, todėl relių vardų grandinė konfigūracijoje nepakeičia naudojamo kelio į perdavimo serverį. Ir relė persiunčia paketus; ji nesuteikia leidimo, ar persiunčiamas srautas leidžiamas, vis dar sprendžia paskirties vietos įeinimo taisyklės. Vaidmuo ir jo reikalavimai aprašyti relės konfigūracijos dokumentacijoje.

Skelbkite relę iš paskirties vietos, o ne iš kliento

Tai inversija, kuri suvalgo daugiausia valandų. Relių sąrašas priklauso serveriui, kurį bandote pasiekti, nes jis kitiems partneriams pasako, kurias reles galima naudoti tam serveriui pasiekti. Padėjus jį kliente, kuris pradeda ryšį, nieko neduodama krypčiai, kurios klientui reikia:

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

Partneriai tą sąrašą praneša kartu su savo adresais, kai registruojasi lighthouse, todėl paskelbimas plinta per aptikimą, o ne per tiesioginį mainą. Jei paskirties vieta nepasiekia jokio lighthouse, jos relių sąrašas niekada neplinta, ir teisingai sukonfigūruota relė lieka nenaudojama. Tas gedimas atrodo lygiai kaip sugedusi relė ir ja nėra.

Duokite paskirties vietai paleidimo kelią tame pačiame žingsnyje. Statinis serverių žemėlapis susieja Nebula adresą su viešu galiniu tašku, kad pirmas rankos paspaudimas turėtų kur eiti, ir jam reikia įrašo relei, jei paskirties vieta turi priimti persiųstą srautą iš serverių, kurių nepasiekia tiesiogiai:

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

Leiskite prisijungiančiam partneriui naudoti relę

Inicijuojančiai pusei reikia savo leidimo. relay.use_relays pagal nutylėjimą įjungtas, todėl atvejis, kurio verta ieškoti, yra aiškus false, dažnai nukopijuotas iš šablono, rašyto prieš atsirandant relės funkcijai, arba paliktas ankstesnio bandymo priverstinai naudoti tiesioginius kelius:

relay:
  use_relays: true

Leidimas šioje pusėje nėra vieninteliai vartai. Paskirties vietos įeinimo taisyklės vis dar taikomos persiųstam paketui, o šaltinis, su kuriuo jos lyginamos, yra tapatybė tunelio viduje, o ne pačios relės adresas. Kai persiųstas rankos paspaudimas pasibaigia, o programa vis tiek nepavyksta, perskaitykite paskirties vietos žurnale, koks šaltinis buvo užfiksuotas, prieš perrašydami taisyklę.

NAT perėjimo nustatymai sąveikauja su visu tuo. punchy.punch padeda dviem partneriams atidaryti tiesioginį kelią, o kai tai pavyksta, nėra persiųsto srauto, kurį būtų galima stebėti; tai sėkmė, o ne trūkstama relė. Pora, kuri veikia su pertraukomis, dažniausiai reiškia, kad punch pavyksta tik kartais, todėl testuokite tą porą kelis kartus, o ne darykite išvadą iš vieno bandymo.

Patikrinkite su pora, kuri nepavyko, ir tada įkelkite iš naujo

Testuokite tuos du serverius, kurie tikrai nepavyko, su programa, kurios jiems reikia. Sėkmingas ping iš jūsų darbo stoties į pačios relės paslaugą nieko neįrodo apie persiuntimą tarp dviejų kitų partnerių, ir tai yra dažniausias klaidingas teigiamas rezultatas visoje šioje procedūroje.

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

Įkelkite iš naujo, o ne perkraukite, ir patvirtinkite, kad veikiantis procesas perėmė jūsų redaguotą failą. Perkrovimas nutraukia kiekvieną tunelį ir padaro kitą testą sunkiau įskaitomą, o SIGHUP išlaiko procesą ir leidžia jam iš naujo perskaityti konfigūraciją:

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

systemctl reload veikia tik tada, kai vietinis unit apibrėžia ExecReload, o su projektu pateikiamas unit to nedaro, todėl systemctl kill -s HUP yra žingsnis, kuris pavyksta standartinėje instalijoje. Po įkėlimo perskaitykite žurnale konfigūracijos kelią, kurį atidarė procesas, kad žinotumėte, jog buvo perskaitytas naujas failas, o ne tas, kurį laikėte įkeltu.

Relės nustatymai ir NAT punch abu veikia kelią; nė vienas neveikia tapatybės. Jei pora vis tiek nepavyksta rankos paspaudimo, kai am_relay, relays ir use_relays patvirtinti veikiančioje konfigūracijoje, patikrinkite, ar abu serveriai pateikia sertifikatus, išduotus vardams, su kuriais jie sukonfigūruoti, ir ar CA yra ta pati abiejose pusėse. Laikykite sertifikatų ir ugniasienės konfigūraciją nepakeistą, kol keičiate vieną transporto nustatymą vienu metu, nes sertifikato pakeitimas ir relės pakeitimas tame pačiame teste nieko nesako apie tai, kuris iš jų pajudino rankos paspaudimą. Vardo ar CA neatitikimas nepavyksta toje pačioje vietoje kaip relė, kuri niekada nebuvo rasta, ir todėl ši priešprieša priklauso tam pačiam žingsniui.

Tada patvirtinkite, kad kiekvienas teiginys yra faile, kuriam priklauso:

• am_relay: true perdavimo serveryje, ir tas serveris pasiekiamas per UDP iš abiejų pusių.
• relays: su to serverio Nebula adresu paskirties vietoje.
• use_relays: true partneryje, kuris pradeda ryšį.
• Įeinimo taisyklės paskirties vietoje, kurios ir po kelio pakeitimo leidžia tikrąjį šaltinį.