Nebula static_host_map: adresa, ktorú maják nemôže dať

Každý maják môže hostiteľovi povedať o každom ďalšom peere okrem toho, kde žije samotný maják. Niečo musí byť známe predtým, ako overlay existuje, a Nebula to niečo ukladá do jednej malej mapy. Mapa spája overlay identitu s adresou, ktorá funguje v bežnej sieti. Všetko, čo sa naučí neskôr, závisí od toho, či je toto spojenie správne.

Dve adresy s dvoma úlohami

Každý host Nebula má overlay adresu, ktorá zostáva pevná, kým sa zariadenie pohybuje medzi sieťami. Táto adresa je identita, ktorú používajú certifikáty, pravidlá firewallu a vzťahy peerov, a sama o sebe nikam nesmeruje. Dosiahnuteľný koncový bod je niečo iné: názov hostiteľa alebo adresa v podkladovej sieti plus UDP port, a mení sa vždy, keď stroj zmení umiestnenie. Statická mapa je spojenie medzi oboma.

Do mapy patria len hostitelia, ktoré treba vytáčať za studena, čo zvyčajne znamená majáky a možno jeden relay. Udržať ten zoznam krátky je cieľ návrhu, pretože každý ručný záznam sa stáva faktom, ktorý musí niekto udržiavať. Zameniť oba typy adries je obvyklá chyba konfigurácie: verejná adresa vložená do zoznamu majákov nespustí zisťovanie.

Identita ide tam, kde sa identita očakáva. Dosiahnuteľnosť ide do mapy.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatómia záznamu v mape

Kľúčom je overlay adresa zapísaná ako reťazec v úvodzovkách a hodnotou je zoznam koncových bodov, takže jedna identita môže mať viac vstupov. Každý koncový bod nesie hostiteľa a port a port musí zodpovedať tomu, na čom druhá strana skutočne počúva. Predvolená hodnota Nebula je UDP 4242, čo je východiskový bod, nie sľub o vašom nasadení.

Viac koncových bodov je užitočných, keď má maják viac ako jednu cestu dovnútra, napríklad verejnú adresu a súkromnú adresu pre hostiteľov v tom istom segmente. Klient ich skúša v poradí, preto dajte najspoľahlivejší prvý. Pri IPv6 obaľte adresu do hranatých zátvoriek pred pridaním portu; chyba tu vytvorí chybu parsovania, ktorá ukazuje na nesprávny riadok.

Nesprávny port vytvára ticho namiesto chyby, pretože UDP nemá handshake, ktorým by odmietol. Preto sa oplatí skontrolovať formát záznamu proti referencii Nebula pre static_host_map a nie proti pamäti. Referencia pokrýva aj zoznamy koncových bodov a správanie obnovy DNS.

Bootstrap musí fungovať pred overlayom

DNS názov v mape sa musí preložiť cez resolver, ktorý hostiteľ má pred akýmkoľvek tunelom, teda bežný systémový resolver. Otestujte to z toho istého stroja, pri štarte, so zastaveným overlayom. Názov, ktorý sa prekladá len cez vlastný DNS overlaya, nemôže overlay nabootovať. Rovnaký test platí pre trasu: pravidlo firewallu, ktoré povoľuje overlay, ale nie prvú výmenu UDP, zablokuje prvý paket.

Overte port nástrojom UDP namiesto predpokladu, že je otvorený. Potvrďte, že každé presmerovanie portu na ceste smeruje na správneho interného hostiteľa a že existuje spiatočná cesta. Ak sa názov hostiteľa prekladá na viac adries, otestujte každú, pretože klient môže vybrať adresu, ktorú ste nikdy neoverili.

Statické záznamy sa vytáčajú priamo a nikdy sa nepýtajú majáka. Preto zlyhanie tu vyzerá ako obyčajný timeout bez účasti peera.

Čo sa deje po prvom handshake

Keď hostiteľ dosiahne maják, dozvie sa o peerovi a jeho dosiahnuteľných adresách bez ďalších ručných záznamov. Hostitelia, ktorí sa od posledného pripojenia presunuli, sa stanú zistiteľnými cez ten kanál. To je odmena za to, že ručná mapa zostáva malá.

Hostitelia môžu tiež inzerovať vlastné ďalšie dosiahnuteľné adresy, a tak peer za známou verejnou adresou pomáha ostatným ho nájsť. Tie inzeráty sa učia, neukladajú sa do statickej mapy.

Správanie obnovy je dôležité pre koncové body zapísané ako DNS názvy, pretože preložená adresa sa môže zmeniť, kým proces beží ďalej. Nastavenia Nebula riadia, ako tieto vyhľadávania prebiehajú, vrátane toho, ktorý resolver sa používa, preto ich čítajte namiesto predpokladu systémovej predvolenej hodnoty. Na hostiteľovi, ktorého resolver sa zmení, keď sa zdvihne tunel, môže nesprávne nastavenie premeniť fungujúci bootstrap na názov, ktorý sa prestane prekladať uprostred relácie. Pripnutie vyhľadávania k stabilnému resolveru je často rozdiel medzi spoľahlivým overlayom a prerušovaným.

Keď zisťovanie funguje a jeden peer nie

Ak sú majáky dosiahnuteľné a väčšina peerov sa pripája, bootstrap nie je problém. Zostávajúca dvojica buď nenájde použiteľnú cestu k sebe, alebo zlyhá nad dosiahnuteľnosťou. Pridanie ďalšieho zápisu adresy majáka neopraví ani jeden z dvoch prípadov.

Skontrolujte dvojicu pred úpravou mapy, na ktorej už stojí všetko ostatné. Zmena mapy naruší každého hostiteľa, takže je to posledná vec, ktorej sa treba dotknúť, nie prvá.

Začnite s certifikátmi od tej istej autority, pretože odmietnutý handshake môže zďaleka vyzerať ako nedosiahnuteľný peer. Potom skontrolujte, či dvojica dokáže vytvoriť priamu cestu a či je relay nakonfigurovaný pre siete, ktoré odmietajú priamy prenos. Relay pridáva skok a závislosť, ale je to podporovaná odpoveď, a oprava cesty peera je iná úloha než oprava zisťovania.