Nebula advertise_addrs nebo static_host_map: vybírejte podle vlastníka

Nastavení static_host_map a advertise_addrs obě staví adresu před peer a odpovídají na různé otázky. Jedno je místní soubor se seznamem overlay adresy a koncového bodu underlay, na který se připojit. Druhé je hostitel, který svým majákům říká, které další koncové body se k němu mohou dostat. Skutečný rozdíl je vlastnictví: mapu udržuje každý, kdo ji potřebuje, a inzerát sám hostitel.

Rozhodujte se podle toho, kdo informaci vlastní

Každý měnící se peer ve statickém souboru každého peera je údržbová práce, která roste s druhou mocninou flotily. To je praktický důvod sáhnout po druhém nastavení, když hostitel sám zná odpověď.

Otázka vlastnictví také předpovídá, co se stane, když se adresa změní. Se statickou mapou si někdo musí pamatovat každého peera, který drží starý záznam. S inzerátem hostitel zveřejní nový koncový bod a jeho majáky ho předají dál, takže změna zůstane lokální na stroji, který se přestěhoval.

Bootstrap stále potřebuje statické záznamy

Klient musí dosáhnout alespoň jednoho majáku, než se může někoho zeptat na jiné peery. Tento první skok nemůže přijít z objevování, takže přichází z statický záznam v konfiguraci klienta. Udělejte tento jeden záznam správným a zbytek overlay se dá naučit.

Záznam mapy páruje Nebula adresu s jedním nebo více dostupnými koncovými body IP nebo DNS a porty. Držet tam majáky je normální; držet tam každého peera je vzor, který špatně stárne, protože každý nový peer znamená úpravu souborů na strojích, které možná neovládáte. Držte seznam dost krátký, aby ho člověk ještě mohl ověřit přečtením.

Inzerujte, když hostitel zná koncový bod

Hostitel za přesměrováním portů je dostupný na veřejné adrese, která není přiřazena žádnému z jeho vlastních rozhraní. Nemůže tuto adresu objevit tím, že se podívá na sebe. advertise_addrs mu umožňuje zveřejnit koncový bod přes jeho majáky, aby se ostatní peerové naučili cestu, která skutečně funguje. Nastavení existuje právě proto, že hostitel je jediná strana, která ví, že mapování bylo vytvořeno.

Použijte adresu a port, na které se ostatní peerové skutečně dostanou. Stejná úvaha platí pro hostitele s několika síťovými cestami, kde je jedna cesta vhodnější pro peery v určité síti. Inzerce je tvrzení o underlay, ne žádost o cokoli. Když se mapování změní, aktualizujte inzerát na hostiteli a nechte objevování, ať ho nese, místo abyste upravovali statické soubory po celé flotile.

Inzerce není dostupnost

Zveřejnění koncového bodu nevytváří pravidlo přesměrování routeru, neotevírá firewall výše v cestě a nezpůsobuje, že se DNS jméno přeloží. To jsou oddělené kusy práce a správný inzerát s chybějícím přesměrováním portu vytváří přesně tu poruchu, kterou jste se snažili opravit. Inzerce je tvrzení o dostupnosti, ne mechanismus, který ji ustavuje.

Než obviníte objevování, zkontrolujte cestu zvenčí. Peer, který se naučí koncový bod, ale nedokáže dokončit handshake, má problém se směrováním nebo filtrováním na underlay a opakování stejné adresy v obou nastaveních to nezmění.

Držte overlay adresu oddělenou od koncového bodu

Certifikát uzlu identifikuje jeho Nebula adresu. Inzerované adresy patří podkladové síti a smějí se měnit bez zásahu do certifikátu. Vydání nového certifikátu s jinou overlay IP je jiná operace s vlastními důsledky pro každý vztah důvěry, který připnul tu starou. Držte obě změny oddělené v runbooku, jinak bude přesun koncového bodu zaznamenán jako opětovné vydání.

Když triage uvízne, výslovně oddělte obě vrstvy: vrací objevování očekávaný koncový bod a dostane se k němu handshake? Pokud je objevování správné a pakety selhávají, problém je pod overlay. Pokud je objevování špatné, problém je v mapě nebo inzerátu a oprava patří tam.