Przekaźnik Nebula skonfigurowany, ale nieużywany: trzy ustawienia do sprawdzenia

Dodałeś host przekaźnika, wpisałeś jego adres Nebula do konfiguracji, a dwa peery nadal się nie porozumiewają. Dzieje się tak, ponieważ ścieżka przekaźnika wymaga trzech osobnych deklaracji, które muszą się zgadzać, a tylko jedna z nich znajduje się na maszynie, którą prawdopodobnie edytowałeś. Śledziłem to dwa razy: raz host przekazujący nigdy nie dostał roli przekaźnika, a raz ustawienia zapisano po niewłaściwej stronie połączenia. Poniższa kolejność sprawdza rolę, ogłoszenie i uprawnienie właśnie w tej kolejności, a każdy krok ma polecenie, które mówi, czy kontynuować.

Zmapuj trzy role, zanim edytujesz konfigurację

Nebula daje każdemu hostowi zadanie, a zadania nie są dziedziczone. Lighthouse odpowiada na pytania w rodzaju gdzie jest ten peer, żeby hosty mogły się nawzajem znaleźć. Przekaźnik forwarduje ruch między dwoma peerami, które nie mają działającej ścieżki bezpośredniej. Zwykły host nie robi ani jednego, ani drugiego. Trzy istotne ustawienia mieszkają na trzech różnych maszynach i dlatego konfiguracja klienta, która wygląda na kompletną, może zostawić oba peery w oczekiwaniu.

# 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 objaw rozdziela dwie klasy awarii. Jeśli oba peery wymieniają się na listach i log pokazuje próby handshake’u, które nigdy się nie kończą, wykrywanie działa, a ścieżkę danych blokuje NAT albo zapora. Jeśli peer w ogóle nie poznaje adresu drugiego, problem leży w lighthouse albo w jego statycznej mapie hostów, a ustawienia przekaźnika tego nie naprawią.

Potwierdź, którą konfigurację każdy host faktycznie wczytał, zanim zmienisz cokolwiek innego. Unit, który czyta inną ścieżkę niż edytowany plik, jest częstą i żenującą przyczyną tego, że „zmiana nic nie dała”:

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

Linia wersji ma znaczenie w mieszanej flocie. Obsługa przekaźników, zachowanie punchowania i akceptowane klucze konfiguracji nie są identyczne między wydaniami, więc nie zakładaj, że starszy build rozumie sekcję, dla której go nie napisano. Ustaw hosty na tej samej serii minor, następnie uruchom nebula -test -config /etc/nebula/config.yml na każdym hoście i porównaj wynik, zanim zaczniesz debugować transport, którego kod nie implementuje.

Włącz rolę przekazywania na hoście przekaźnika

Rola przekaźnika to jedna flaga na hoście przekazującym i jest oddzielona od bycia lighthouse’em. Host z włączonym wykrywaniem i wyłączonym przekazywaniem przez przekaźnik nadal jest tylko usługą wykrywania. Na przekaźniku:

relay:
  am_relay: true

Ta flaga deklaruje intencję; nie tworzy osiągalności. Przekaźnik musi być osiągalny z obu peerów, co w praktyce oznacza publiczny adres, przychodzący UDP na porcie Nebula otwarty w zaporze hosta i w dowolnej grupie bezpieczeństwa chmury oraz brak podwójnego NAT przed nim. Sprawdź nasłuchujący socket, a potem obserwuj, czy pakiety peera dochodzą:

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

Dwa ograniczenia oszczędzają czas później. Do przekaźnika nie można dotrzeć przez inny przekaźnik, więc łańcuch nazw przekaźników w konfiguracji nie zastępuje dania hostowi przekazującemu użytecznej ścieżki. A przekaźnik przekazuje pakiety; nie przyznaje uprawnień, o tym, czy przekazywany strumień jest dozwolony, nadal decydują własne reguły przychodzące celu. Rola i jej wymagania są opisane w dokumentacji konfiguracji przekaźnika.

Ogłaszaj przekaźnik z celu, nie z klienta

To jest odwrócenie, które zjada najwięcej godzin. Lista przekaźników należy do hosta, do którego próbujesz dotrzeć, bo mówi innym peerom, których przekaźników wolno użyć, żeby ten host osiągnąć. Umieszczenie jej na kliencie, który rozpoczyna połączenie, nic nie daje w kierunku, którego klient potrzebuje:

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

Peery zgłaszają tę listę razem ze swoimi adresami, gdy meldują się w lighthouse, więc ogłoszenie rozchodzi się przez wykrywanie, a nie przez bezpośrednią wymianę. Jeśli cel nie osiąga żadnego lighthouse’u, jego lista przekaźników nigdy się nie rozprzestrzenia i poprawnie skonfigurowany przekaźnik stoi bezczynnie. Ta awaria wygląda dokładnie jak zepsuty przekaźnik i nim nie jest.

Daj celowi ścieżkę startową w tym samym przebiegu. Statyczna mapa hostów wiąże adres Nebula z publicznym punktem końcowym, żeby pierwszy handshake miał gdzie trafić, i potrzebuje wpisu dla przekaźnika, jeśli cel ma przyjmować przekazywany ruch od hostów, do których nie dociera bezpośrednio:

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

Pozwól łączącemu się peerowi użyć przekaźnika

Strona inicjująca potrzebuje własnego uprawnienia. relay.use_relays jest domyślnie włączone, więc przypadkiem wartym szukania jest jawne false, często skopiowane z szablonu napisanego przed powstaniem funkcji przekaźnika albo pozostawione przez wcześniejszą próbę wymuszenia ścieżek bezpośrednich:

relay:
  use_relays: true

Uprawnienie po tej stronie to nie jedyna brama. Reguły przychodzące celu nadal obowiązują dla przekazywanego pakietu, a źródłem, z którym są porównywane, jest tożsamość wewnątrz tunelu, a nie adres samego przekaźnika. Gdy przekazywany handshake się kończy, a aplikacja nadal zawodzi, przeczytaj w logu celu, jakie źródło zostało zapisane, zanim przepiszesz regułę.

Ustawienia przechodzenia przez NAT współdziałają z tym wszystkim. punchy.punch pomaga dwóm peerom otworzyć ścieżkę bezpośrednią, a gdy się to udaje, nie ma ruchu przekaźnika do zaobserwowania; to sukces, a nie brakujący przekaźnik. Para, która działa z przerwami, zwykle oznacza, że punchowanie udaje się tylko czasami, więc testuj tę parę kilka razy zamiast wyciągać wniosek z jednej próby.

Zweryfikuj na parze, która zawiodła, i przeładuj

Testuj te dwa hosty, które naprawdę zawiodły, z aplikacją, której potrzebują. Udany ping z twojej stacji roboczej do samej usługi przekaźnika niczego nie dowodzi o przekazywaniu między dwoma innymi peerami i jest najczęstszym fałszywym pozytywem w całej tej procedurze.

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

Przeładuj zamiast restartować i potwierdź, że działający proces podjął edytowany plik. Restart zrywa każdy tunel i utrudnia odczyt następnego testu, podczas gdy SIGHUP zachowuje proces i każe mu ponownie wczytać konfigurację:

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

systemctl reload działa tylko wtedy, gdy lokalny unit definiuje ExecReload, a unit dostarczany z projektem tego nie robi, więc systemctl kill -s HUP to krok, który udaje się na standardowej instalacji. Po przeładowaniu przeczytaj w journalu ścieżkę konfiguracji, którą otworzył proces, żeby wiedzieć, że wczytano nowy plik, a nie ten, który uważałeś za wczytany.

Ustawienia przekaźnika i punchowanie NAT działają oba na ścieżkę; żadne nie działa na tożsamość. Jeśli para nadal zawodzi na handshake’u, gdy am_relay, relays i use_relays są potwierdzone w działającej konfiguracji, sprawdź, czy oba hosty przedstawiają certyfikaty wystawione dla nazw, z którymi są skonfigurowane, i czy CA jest ten sam po obu stronach. Utrzymuj konfigurację certyfikatów i zapory w stanie niezmienionym, zmieniając jedno ustawienie transportu naraz, ponieważ zmiana certyfikatu i zmiana przekaźnika w tym samym teście nic nie mówią o tym, która z nich przesunęła handshake. Niezgodność nazwy lub CA zawodzi w tym samym miejscu co przekaźnik, którego nigdy nie znaleziono, i dlatego ta kontrola krzyżowa należy do tego samego przebiegu.

Następnie potwierdź, że każda deklaracja jest w pliku, do którego należy:

• am_relay: true na hoście przekazującym, a ten host osiągalny przez UDP z obu stron.
• relays: z adresem Nebula tego hosta na celu.
• use_relays: true na peerze, który rozpoczyna połączenie.
• Reguły przychodzące na celu, które nadal pozwalają na rzeczywiste źródło po zmianie ścieżki.