Nebula advertise_addrs sau static_host_map: alege după proprietar
O hartă statică este întreținută de fiecare peer care o apelează; o adresă anunțată este publicată de gazdă. Alege după cine cunoaște punctul final.
Setările static_host_map și advertise_addrs ambele pun o adresă în fața unui peer și răspund la întrebări diferite. Una este un fișier local care listează o adresă overlay și punctul final underlay la care se apelează. Cealaltă este o gazdă care le spune farurilor sale ce puncte finale suplimentare o pot atinge. Proprietatea este diferența reală: harta este întreținută de toți cei care au nevoie de ea, iar anunțul de gazda însăși.
Decide după cine deține informația
| Setting | Where it lives | Best for |
|---|---|---|
static_host_map | Every peer that needs the entry | Bootstrap endpoints, deliberately fixed paths |
advertise_addrs | The host's own config | Endpoints the host cannot otherwise discover |
Fiecare peer care se schimbă în fișierul static al fiecărui peer este o muncă de întreținere care crește cu pătratul flotei. Acesta este motivul practic de a apela la cealaltă setare ori de câte ori gazda însăși știe răspunsul.
Întrebarea proprietății prezice și ce se întâmplă când se schimbă o adresă. Cu o hartă statică, cineva trebuie să-și amintească fiecare peer care deține intrarea veche. Cu un anunț, gazda publică noul punct final și farurile sale îl transmit, așa că schimbarea rămâne locală pe mașina care s-a mutat.
Bootstrap-ul are încă nevoie de intrări statice
Un client trebuie să ajungă la cel puțin un far înainte de a putea întreba pe cineva despre alți peers. Acel prim salt nu poate veni din descoperire, așa că vine din o intrare statică în configurația clientului. Fă acea singură intrare corectă și restul overlay-ului poate fi învățat.
O intrare a hărții asociază o adresă Nebula cu unul sau mai multe puncte finale IP sau DNS accesibile și porturi. A ține farurile acolo este normal; a ține fiecare peer acolo este modelul care îmbătrânește prost, pentru că fiecare peer nou înseamnă editarea fișierelor pe mașini pe care poate nu le controlezi. Ține lista destul de scurtă încât o persoană să o poată verifica citind-o.
Anunță când gazda cunoaște punctul final
O gazdă din spatele redirecționării porturilor este accesibilă la o adresă publică care nu este atribuită niciuneia dintre interfețele sale. Nu poate descoperi acea adresă uitându-se la sine. advertise_addrs îi permite să publice punctul final prin farurile sale, astfel încât alți peers să învețe o cale care funcționează cu adevărat. Setarea există exact pentru că gazda este singura parte care știe că maparea a fost făcută.
Folosește adresa și portul la care alți peers pot ajunge cu adevărat. Același raționament se aplică unei gazde cu mai multe căi de rețea, unde o cale este preferabilă pentru peers dintr-o rețea anume. Anunțul este o afirmație despre underlay, nu o cerere pentru ceva. Când maparea se schimbă, actualizează anunțul la gazdă și lasă descoperirea să îl ducă, în loc să editezi fișiere statice în toată flota.
Anunțul nu este accesibilitate
Publicarea unui punct final nu creează regula de redirecționare a routerului, nu deschide un firewall în amonte și nu face un nume DNS să se rezolve. Sunt piese de lucru separate, iar un anunț corect cu o redirecționare de port lipsă produce exact defecțiunea pe care încercai să o repari. Anunțul este o afirmație despre accesibilitate, nu un mecanism care o stabilește.
Verifică calea din exterior înainte de a da vina pe descoperire. Un peer care învață punctul final dar nu poate finaliza un handshake are o problemă de rutare sau filtrare pe underlay, iar repetarea aceleiași adrese în ambele setări nu va schimba asta.
Ține adresa overlay separată de punctul final
Certificatul nodului îi identifică adresa Nebula. Adresele anunțate aparțin rețelei de dedesubt și pot fi schimbate fără a atinge certificatul. Emiterea unui certificat nou cu un IP overlay diferit este o operațiune diferită, cu consecințele sale pentru fiecare relație de încredere care a fixat-o pe cea veche. Ține cele două schimbări separate în runbook, altfel o mutare de punct final va fi înregistrată ca o reemitere.
Când triajul se blochează, separă explicit cele două straturi: descoperirea returnează punctul final așteptat și un handshake ajunge la el? Dacă descoperirea este corectă și pachetele eșuează, problema este sub overlay. Dacă descoperirea este greșită, problema este în hartă sau în anunț, iar corectarea aparține acolo.