Přeposílací uzel Nebula nakonfigurován, ale nevyužit: tři nastavení ke kontrole

Přidali jste přeposílací host, zapsali jeho adresu Nebula do konfigurace a dva protějšky spolu pořád nemluví. Děje se to proto, že cesta přes přeposílací uzel potřebuje tři samostatná prohlášení, která se musí shodovat, a jen jedno z nich je na stroji, který jste pravděpodobně upravovali. Sledoval jsem to dvakrát: jednou předávací host nikdy nedostal roli přeposílacího uzlu a jednou byla nastavení zapsaná na špatné straně spojení. Následující posloupnost kontroluje roli, ohlášení a oprávnění v tomto pořadí a každý krok má příkaz, který vám řekne, zda pokračovat.

Zmapujte tři role, než upravíte konfiguraci

Nebula dává každému hostu úkol a úkoly se nedědí. Lighthouse odpovídá na otázky typu kde je tento protějšek, aby se hosty navzájem našly. Přeposílací uzel předává provoz mezi dvěma protějšky, které nemají funkční přímou cestu. Běžný host nedělá ani jedno. Tři důležitá nastavení sídlí na třech různých strojích, a proto konfigurace klienta, která vypadá úplně, může nechat oba protějšky čekat.

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

Jeden příznak odděluje dvě třídy selhání. Pokud se oba protějšky navzájem uvádějí a log ukazuje pokusy o handshake, které nikdy neskončí, zjišťování funguje a datovou cestu blokuje NAT nebo firewall. Pokud se protějšek vůbec nedozví adresu druhého, problém je v lighthouse nebo v jeho statické mapě hostů a nastavení přeposílacího uzlu to nespraví.

Potvrďte, kterou konfiguraci každý host skutečně načetl, než změníte cokoli jiného. Unit, který čte jinou cestu než soubor, který jste upravili, je častou a trapnou příčinou toho, že „změna nic neudělala“:

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

Řádek verze má význam ve smíšené flotile. Zpracování přeposílacích uzlů, chování punchování a přijímané konfigurační klíče nejsou napříč vydáními totožné, takže nepředpokládejte, že starší build rozumí sekci, pro kterou nebyl napsán. Srovnejte hosty na stejnou minor řadu, poté spusťte nebula -test -config /etc/nebula/config.yml na každém hostu a porovnejte výstup, než začnete ladit transport, který kód neimplementuje.

Zapněte roli předávání na přeposílacím hostu

Role přeposílacího uzlu je jediný příznak na předávacím hostu a je oddělená od toho být lighthouse. Host se zapnutým zjišťováním a vypnutým předáváním přes přeposílací uzel je pořád jen služba zjišťování. Na přeposílacím uzlu:

relay:
  am_relay: true

Tento příznak deklaruje záměr; nevytváří dosažitelnost. Přeposílací uzel musí být dosažitelný z obou protějšků, což v praxi znamená veřejnou adresu, příchozí UDP na portu Nebula otevřený ve firewallu hostu a v jakékoli cloudové bezpečnostní skupině a žádný dvojitý NAT před ním. Zkontrolujte naslouchající socket a potom sledujte, zda přicházejí pakety protějšku:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

Dvě omezení šetří čas později. K přeposílacímu uzlu se nedostanete přes jiný přeposílací uzel, takže řetěz jmen uzlů v konfiguraci nenahrazuje použitelnou cestu k předávacímu hostu. A přeposílací uzel předává pakety; neuděluje oprávnění, o tom, zda je předávaný tok povolen, rozhodují dál vlastní příchozí pravidla cíle. Role a její požadavky jsou v dokumentaci ke konfiguraci přeposílacího uzlu.

Ohlašte přeposílací uzel z cíle, ne z klienta

To je obrácení, které spotřebuje nejvíc hodin. Seznam přeposílacích uzlů patří hostu, ke kterému se snažíte dostat, protože ostatním protějškům říká, které uzly lze k dosažení tohoto hostu použít. Umístit ho na klienta, který spojení zahajuje, nic nedělá pro směr, který klient potřebuje:

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

Protějšky hlásí tento seznam spolu se svými adresami, když se hlásí v lighthouse, takže ohlášení se šíří zjišťováním, a ne přímou výměnou. Pokud cíl nedosáhne žádného lighthouse, jeho seznam uzlů se nikdy nerozšíří a správně nastavený přeposílací uzel zůstane nečinný. Toto selhání vypadá přesně jako rozbitý uzel a není jím.

Dejte cíli startovní cestu ve stejném kroku. Statická mapa hostů váže adresu Nebula k veřejnému koncovému bodu, aby první handshake měl kam jít, a potřebuje záznam pro přeposílací uzel, pokud má cíl přijímat předávaný provoz od hostů, ke kterým se nedostane přímo:

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

Nechte připojující se protějšek použít přeposílací uzel

Zahajující strana potřebuje vlastní oprávnění. relay.use_relays je ve výchozím stavu zapnuté, takže případem, který stojí za hledání, je výslovné false, často zkopírované ze šablony napsané před vznikem funkce přeposílání nebo ponechané dřívějším pokusem vynutit přímé cesty:

relay:
  use_relays: true

Oprávnění na této straně není jediná brána. Příchozí pravidla cíle platí i pro předávaný paket a zdrojem, se kterým se porovnávají, je identita uvnitř tunelu, nikoli adresa samotného přeposílacího uzlu. Když předávaný handshake skončí a aplikace přesto selhává, přečtěte v logu cíle, jaký zdroj si poznamenal, než přepíšete pravidlo.

Nastavení průchodu NAT s tím vším spolupůsobí. punchy.punch pomáhá dvěma protějškům otevřít přímou cestu, a když se to podaří, není pozorovatelný žádný provoz přes přeposílací uzel; to je úspěch, ne chybějící uzel. Pár, který funguje přerušovaně, obvykle znamená, že punchování občas vyjde, takže tento pár testujte několikrát, místo abyste z jednoho pokusu dělali závěr.

Ověřte s párem, který selhal, a poté znovu načtěte

Testujte ty dva hosty, které skutečně selhaly, s aplikací, kterou potřebují. Úspěšný ping z vaší pracovní stanice na službu samotného přeposílacího uzlu nic nedokazuje o předávání mezi dvěma jinými protějšky a je to nejčastější falešný pozitiv v celém tomto postupu.

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

Načítejte znovu místo restartu a potvrďte, že běžící proces převzal soubor, který jste upravili. Restart strhne každý tunel a dělá další test hůř čitelným, zatímco SIGHUP proces zachová a nechá ho znovu načíst konfiguraci:

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload funguje jen tehdy, když místní unit definuje ExecReload, a unit dodávaný s projektem to nedělá, takže systemctl kill -s HUP je krok, který na standardní instalaci vyjde. Po znovunačtení si přečtěte v journalu cestu ke konfiguraci, kterou proces otevřel, abyste věděli, že se načetl nový soubor, a ne ten, který jste považovali za načtený.

Nastavení přeposílacího uzlu a punchování NAT působí obě na cestu; ani jedno nepůsobí na identitu. Pokud pár stále selhává v handshake, když jsou am_relay, relays a use_relays potvrzené v běžící konfiguraci, zkontrolujte, zda oba hosty předkládají certifikáty vydané pro jména, se kterými jsou nastavené, a zda je CA na obou stranách stejná. Držte konfiguraci certifikátů a firewallu nezměněnou, zatímco měníte jedno transportní nastavení po druhém, protože změna certifikátu a změna přeposílacího uzlu ve stejném testu nic neříkají o tom, která z nich posunula handshake. Neshoda jména nebo CA selhává na stejném místě jako uzel, který se nikdy nenašel, a proto tato protikontrola patří do stejného kroku.

Poté potvrďte, že každé prohlášení je v souboru, kam patří:

• am_relay: true na předávacím hostu a tento host dosažitelný přes UDP z obou stran.
• relays: s adresou Nebula tohoto hostu na cíli.
• use_relays: true na protějšku, který spojení zahajuje.
• Příchozí pravidla na cíli, která i po změně cesty povolují skutečný zdroj.