Nebula static_host_map: adresa pe care un far nu o poate da

Fiecare far poate spune unui gazdă despre orice alt partener, în afară de locul unde se află farul însuși. Ceva trebuie să fie cunoscut înainte ca overlay-ul să existe, iar Nebula pune acel ceva într-o hartă mică. Harta asociază o identitate overlay cu o adresă care funcționează în rețeaua obișnuită. Tot ce se învață mai târziu depinde de această asociere să fie corectă.

Două adrese cu două roluri

Fiecare gazdă Nebula are o adresă overlay care rămâne fixă în timp ce dispozitivul se deplasează între rețele. Acea adresă este identitatea folosită de certificate, regulile de firewall și relațiile între parteneri, iar singură nu rutează nicăieri. Punctul terminal accesibil este altceva: un nume de gazdă sau o adresă în rețeaua de bază plus un port UDP, și se schimbă de fiecare dată când mașina își schimbă locația. Harta statică este îmbinarea dintre cele două.

În hartă intră doar gazdele care trebuie apelate la rece, ceea ce înseamnă de obicei fari și poate un releu. Păstrarea listei scurte este un obiectiv de proiectare, pentru că fiecare intrare manuală devine un fapt pe care cineva trebuie să îl întrețină. Confundarea celor două tipuri de adresă este eroarea obișnuită de configurare: o adresă publică pusă în lista farurilor nu pornește descoperirea.

Identitatea merge unde se așteaptă identitate. Accesibilitatea merge în hartă.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomia unei intrări din hartă

Cheia este adresa overlay scrisă ca un șir între ghilimele, iar valoarea este o listă de puncte terminale, așa că o identitate poate avea mai multe puncte de intrare. Fiecare punct terminal poartă un gazdă și un port, iar portul trebuie să corespundă cu ceea ce cealaltă parte ascultă de fapt. Valoarea implicită a Nebula este UDP 4242, care este un punct de plecare, nu o promisiune despre implementarea ta.

Mai multe puncte terminale sunt utile când un far are mai mult de o cale de intrare, cum ar fi o adresă publică și o adresă privată pentru gazdele din același segment. Clientul le încearcă în ordine, așa că pune-o pe cea mai fiabilă prima. Pentru IPv6, pune adresa între paranteze drepte înainte de a adăuga portul; o greșeală aici produce o eroare de analiză care indică linia greșită.

Un port greșit produce tăcere în loc de eroare, pentru că UDP nu are handshake cu care să refuze. De aceea merită verificat formatul intrării față de referința static_host_map a Nebula și nu față de memorie. Referința acoperă și listele de puncte terminale și comportamentul de reîmprospătare DNS.

Pornirea trebuie să funcționeze înainte de overlay

Un nume DNS din hartă trebuie rezolvat prin resolverul pe care gazda îl are înainte de a exista orice tunel, adică resolverul obișnuit al sistemului. Testează asta de pe aceeași mașină, la pornire, cu overlay-ul oprit. Un nume care se rezolvă doar prin DNS-ul propriu al overlay-ului nu poate porni overlay-ul. Aceeași probă se aplică rutei: o regulă de firewall care permite overlay-ul dar nu primul schimb UDP blochează primul pachet.

Verifică portul cu un instrument UDP în loc să presupui că este deschis. Confirmă că orice redirecționare de port de pe cale țintește gazda internă corectă și că există o cale de întoarcere. Dacă numele de gazdă se rezolvă în mai multe adrese, testează fiecare, pentru că un client poate alege o adresă pe care nu ai verificat-o niciodată.

Intrările statice sunt apelate direct și nu întreabă niciodată un far. De aceea o defecțiune aici arată ca un timeout obișnuit fără niciun partener implicat.

Ce se întâmplă după primul handshake

Odată ce o gazdă ajunge la un far, învață despre parteneri și adresele lor accesibile fără mai multe intrări manuale. Gazdele care s-au deplasat de la ultima conexiune devin descoperibile prin acel canal. Aceasta este răsplata pentru păstrarea hărții manuale mici.

Gazdele pot anunța și propriile adrese accesibile suplimentare, și astfel un partener aflat în spatele unei adrese publice cunoscute îi ajută pe alții să îl găsească. Acele anunțuri se învață, nu se scriu în harta statică.

Comportamentul de reîmprospătare contează pentru punctele terminale scrise ca nume DNS, pentru că o adresă rezolvată se poate schimba în timp ce procesul continuă să ruleze. Setările Nebula controlează modul în care au loc acele căutări, inclusiv ce resolver este folosit, așa că citește-le în loc să presupui valoarea implicită a sistemului. Pe o gazdă al cărei resolver se schimbă când urcă un tunel, setarea greșită poate transforma o pornire funcțională într-un nume care nu se mai rezolvă la mijlocul sesiunii. Fixarea căutării pe un resolver stabil este adesea diferența dintre un overlay fiabil și unul intermitent.

Când descoperirea funcționează și un partener nu

Dacă farurile sunt accesibile și majoritatea partenerilor se conectează, pornirea nu este problema. Perechea rămasă fie nu găsește o cale utilizabilă una spre cealaltă, fie eșuează deasupra accesibilității. Adăugarea unei alte grafii a adresei farului nu poate repara niciunul dintre cele două cazuri.

Verifică perechea înainte de a edita harta pe care se sprijină deja tot restul. O schimbare a hărții deranjează fiecare gazdă, deci este ultimul lucru la care se umblă, nu primul.

Începe cu certificate de la aceeași autoritate, pentru că un handshake respins poate părea de la distanță un partener inaccesibil. Apoi verifică dacă perechea poate stabili o cale directă și dacă un releu este configurat pentru rețelele care refuză traficul direct. Un releu adaugă un salt și o dependență, dar este un răspuns acceptat, iar repararea căii perechii este o altă sarcină decât repararea descoperirii.