Nebula static_host_map: adresa, kterou maják nemůže dát

Každý maják může hostiteli říct o každém dalším peerovi kromě místa, kde žije sám maják. Než overlay existuje, musí být něco známo, a Nebula to něco ukládá do jedné malé mapy. Mapa spojuje overlay identitu s adresou, která funguje v běžné síti. Vše, co se naučí později, závisí na tom, že je toto spojení správné.

Dvě adresy se dvěma úkoly

Každý host Nebula má overlay adresu, která zůstává pevná, zatímco se zařízení pohybuje mezi sítěmi. Tato adresa je identita používaná certifikáty, pravidly firewallu a vztahy peerů a sama o sobě nikam nesměruje. Dosažitelný koncový bod je něco jiného: název hostitele nebo adresa v podkladové síti plus UDP port, a mění se vždy, když stroj změní umístění. Statická mapa je spojení mezi oběma.

Do mapy patří jen hostitelé, které je nutné vytáčet za studena, což obvykle znamená majáky a možná jeden relay. Udržet seznam krátký je cíl návrhu, protože každý ruční záznam se stává faktem, který musí někdo udržovat. Zaměnit oba typy adres je obvyklá chyba konfigurace: veřejná adresa vložená do seznamu majáků nespustí zjišťování.

Identita patří tam, kde se identita očekává. Dosažitelnost patří do mapy.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomie záznamu v mapě

Klíčem je overlay adresa zapsaná jako řetězec v uvozovkách a hodnotou je seznam koncových bodů, takže jedna identita může mít několik vstupních bodů. Každý koncový bod nese hostitele a port a port musí odpovídat tomu, na čem druhá strana skutečně poslouchá. Výchozí hodnota Nebula je UDP 4242, což je výchozí bod, nikoli slib o vašem nasazení.

Několik koncových bodů je užitečné, když má maják více než jednu cestu dovnitř, například veřejnou adresu a soukromou adresu pro hostitele ve stejném segmentu. Klient je zkouší v pořadí, proto dejte nejspolehlivější první. U IPv6 obalte adresu do hranatých závorek, než připojíte port; chyba zde vytvoří chybu parsování, která ukazuje na nesprávný řádek.

Špatný port vytváří ticho místo chyby, protože UDP nemá handshake, kterým by odmítl. Proto se vyplatí formát záznamu zkontrolovat proti referenci Nebula pro static_host_map a ne proti paměti. Reference pokrývá také seznamy koncových bodů a chování obnovy DNS.

Bootstrap musí fungovat dřív než overlay

DNS název v mapě se musí přeložit přes resolver, který hostitel má před existencí jakéhokoli tunelu, tedy běžný systémový resolver. Otestujte to ze stejného stroje, při startu, se zastaveným overlayem. Název, který se přeloží jen přes vlastní DNS overlaye, nemůže overlay nabootovat. Stejný test platí pro trasu: pravidlo firewallu, které povolí overlay, ale ne první výměnu UDP, zablokuje počáteční paket.

Ověřte port nástrojem UDP, místo abyste předpokládali, že je otevřený. Potvrďte, že každé přesměrování portu na cestě míří na správného vnitřního hostitele a že existuje zpáteční cesta. Pokud se název hostitele překládá na několik adres, otestujte každou, protože klient může zvolit adresu, kterou jste nikdy nezkontrolovali.

Statické záznamy se vytáčejí přímo a nikdy se neptají majáku. Proto zde selhání vypadá jako obyčejný timeout bez účasti peera.

Co se stane po prvním handshake

Jakmile hostitel dosáhne majáku, dozví se o peerech a jejich dosažitelných adresách bez dalších ručních záznamů. Hostitelé, kteří se od posledního připojení přesunuli, se stanou zjistitelnými přes tento kanál. To je odměna za to, že ruční mapa zůstává malá.

Hostitelé mohou také inzerovat vlastní další dosažitelné adresy, a tak peer za známou veřejnou adresou pomáhá ostatním ho najít. Tyto inzeráty se učí, neukládají se do statické mapy.

Chování obnovy je důležité pro koncové body zapsané jako DNS názvy, protože přeložená adresa se může změnit, zatímco proces běží dál. Nastavení Nebula řídí, jak tato vyhledávání probíhají, včetně toho, který resolver se používá, takže je čtěte, místo abyste předpokládali systémový výchozí stav. Na hostiteli, jehož resolver se změní, když se zvedne tunel, může špatné nastavení proměnit funkční bootstrap v název, který se přestane překládat uprostřed relace. Připoutání vyhledávání ke stabilnímu resolveru je často rozdíl mezi spolehlivým overlayem a přerušovaným.

Když zjišťování funguje a jeden peer ne

Pokud jsou majáky dosažitelné a většina peerů se připojuje, bootstrap není problém. Zbývající dvojice buď nenajde použitelnou cestu k sobě, nebo selhává nad dosažitelností. Přidání dalšího zápisu adresy majáku nemůže opravit ani jeden z případů.

Zkontrolujte dvojici dřív, než upravíte mapu, na které už stojí všechno ostatní. Změna mapy naruší každého hostitele, takže je to poslední věc, které se máte dotknout, ne první.

Začněte certifikáty od stejné autority, protože odmítnutý handshake může zdálky vypadat jako nedosažitelný peer. Pak zkontrolujte, zda dvojice dokáže vytvořit přímou cestu a zda je pro sítě odmítající přímý provoz nakonfigurován relay. Relay přidává skok a závislost, ale je to podporovaná odpověď, a oprava cesty peera je jiný úkol než oprava zjišťování.