Nebula static_host_map: naslov, ki ga svetilnik ne more dati

Vsak svetilnik lahko gostitelju pove o vsakem drugem peeru razen o tem, kje živi svetilnik sam. Nekaj mora biti znano, preden overlay obstaja, in Nebula to nekaj shrani v en majhen zemljevid. Zemljevid poveže identiteto overlay z naslovom, ki deluje v običajnem omrežju. Vse, kar se naučimo pozneje, je odvisno od tega, da je ta povezava pravilna.

Dva naslova z dvema nalogama

Vsak gostitelj Nebula ima naslov overlay, ki ostane nespremenjen, medtem ko se naprava premika med omrežji. Ta naslov je identiteta, ki jo uporabljajo potrdila, pravila požarnega zidu in razmerja med peeri, in sam po sebi ne usmerja nikamor. Dosegljiva končna točka je nekaj drugega: ime gostitelja ali naslov v spodnjem omrežju plus vrata UDP, in se spremeni vsakič, ko naprava zamenja lokacijo. Statični zemljevid je stik med obema.

Na zemljevid gredo le gostitelji, ki jih je treba klicati hladno, kar običajno pomeni svetilnike in morda en relay. Ohranjati ta seznam kratek je cilj zasnove, ker vsak ročni vnos postane dejstvo, ki ga mora nekdo vzdrževati. Zamenjati obe vrsti naslova je običajna konfiguracijska napaka: javni naslov na seznamu svetilnikov ne zažene odkrivanja.

Identiteta gre tja, kjer se identiteta pričakuje. Dosegljivost gre na zemljevid.

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomija vnosa na zemljevidu

Ključ je naslov overlay, zapisan kot niz v narekovajih, vrednost pa je seznam končnih točk, zato ima lahko ena identiteta več vhodov. Vsaka končna točka nosi gostitelja in vrata, vrata pa se morajo ujemati s tem, kar druga stran dejansko posluša. Privzeta vrednost Nebule je UDP 4242, kar je izhodišče in ne obljuba o vaši namestitvi.

Več končnih točk je koristnih, ko ima svetilnik več kot eno pot noter, na primer javni naslov in zasebni naslov za gostitelje v istem segmentu. Odjemalec jih preizkusi po vrsti, zato najbolj zanesljivo postavite prvo. Za IPv6 naslov ovijte v oglate oklepaje, preden dodate vrata; napaka pri tem ustvari napako razčlenjevanja, ki kaže na napačno vrstico.

Napačna vrata ustvarijo tišino namesto napake, ker UDP nima rokovanja, s katerim bi zavrnil. Zato je vredno preveriti obliko vnosa po referenci Nebule za static_host_map in ne po spominu. Referenca pokriva tudi sezname končnih točk in vedenje osveževanja DNS.

Bootstrap mora delovati pred overlay

Ime DNS na zemljevidu se mora razrešiti prek razreševalnika, ki ga gostitelj ima pred katerim koli tunelom, torej običajnega sistemskega razreševalnika. Preizkusite to z istega stroja, ob zagonu, z ustavljenim overlay. Ime, ki se razreši le prek lastnega DNS overlaya, ne more zagnati overlaya. Enak preizkus velja za pot: pravilo požarnega zidu, ki dovoli overlay, ne pa prve izmenjave UDP, blokira prvi paket.

Preverite vrata z orodjem UDP, namesto da predpostavite, da so odprta. Potrdite, da vsako posredovanje vrat na poti cilja na pravega notranjega gostitelja in da povratna pot obstaja. Če se ime gostitelja razreši v več naslovov, preizkusite vsakega, ker lahko odjemalec izbere naslov, ki ga nikoli niste preverili.

Statični vnosi se kličejo neposredno in nikoli ne vprašajo svetilnika. Zato je napaka tu videti kot običajen časovni potek brez sodelujočega peera.

Kaj se zgodi po prvem rokovanju

Ko gostitelj doseže svetilnik, se nauči o peerih in njihovih dosegljivih naslovih brez dodatnih ročnih vnosov. Gostitelji, ki so se premaknili od zadnje povezave, postanejo odkriljivi po tem kanalu. To je nagrada za ohranjanje majhnega ročnega zemljevida.

Gostitelji lahko tudi objavijo svoje dodatne dosegljive naslove, in tako peer za znanim javnim naslovom pomaga drugim, da ga najdejo. Te objave se naučijo, ne vpišejo v statični zemljevid.

Vedenje osveževanja je pomembno za končne točke, zapisane kot imena DNS, ker se razrešeni naslov lahko spremeni, medtem ko proces še teče. Nastavitve Nebule nadzorujejo, kako potekajo ta iskanja, vključno s tem, kateri razreševalnik se uporablja, zato jih preberite, namesto da predpostavite sistemsko privzeto vrednost. Na gostitelju, katerega razreševalnik se spremeni, ko se dvigne tunel, lahko napačna nastavitev spremeni delujoč bootstrap v ime, ki se sredi seje preneha razreševati. Pritrditev iskanja na stabilen razreševalnik je pogosto razlika med zanesljivim overlay in občasnim.

Ko odkrivanje deluje, en peer pa ne

Če so svetilniki dosegljivi in se večina peerov poveže, bootstrap ni težava. Preostali par bodisi ne najde uporabne poti drug do drugega bodisi spodleti nad dosegljivostjo. Dodajanje še enega zapisa naslova svetilnika ne popravi nobenega od obeh primerov.

Preverite par, preden uredite zemljevid, na katerem že stoji vse drugo. Sprememba zemljevida moti vsakega gostitelja, zato se je dotaknite nazadnje, ne prvič.

Začnite s potrdili istega organa, ker je zavrnjeno rokovanje od daleč lahko videti kot nedosegljiv peer. Nato preverite, ali lahko par vzpostavi neposredno pot in ali je relay konfiguriran za omrežja, ki zavračajo neposreden promet. Relay doda en skok in odvisnost, vendar je podprt odgovor, in popravljanje poti para je druga naloga kot popravljanje odkrivanja.