Nebula static_host_map: adres, którego latarnia nie może dać

Każda latarnia może powiedzieć hostowi o każdym innym peerze z wyjątkiem tego, gdzie mieszka sama latarnia. Coś musi być znane, zanim overlay istnieje, a Nebula umieszcza to coś w jednej małej mapie. Mapa łączy tożsamość overlay z adresem, który działa w zwykłej sieci. Wszystko, czego uczymy się później, zależy od tego, czy to zestawienie jest poprawne.

Dwa adresy, dwa zadania

Każdy host Nebula ma adres overlay, który pozostaje stały, gdy urządzenie przemieszcza się między sieciami. Ten adres to tożsamość używana przez certyfikaty, reguły zapory i relacje peerów, a sam nie trasuje nigdzie. Osiągalny punkt końcowy to coś innego: nazwa hosta lub adres w sieci podkładowej plus port UDP, i zmienia się za każdym razem, gdy maszyna zmienia lokalizację. Statyczna mapa jest połączeniem obu.

W mapie są tylko hosty, które trzeba wybierać na zimno, co zwykle oznacza latarnie i być może jeden relay. Utrzymanie tej listy krótkiej jest celem projektowym, bo każdy ręczny wpis staje się faktem, który ktoś musi utrzymywać. Mylenie obu typów adresów to typowy błąd konfiguracji: publiczny adres umieszczony na liście latarni nie uruchamia wykrywania.

Tożsamość idzie tam, gdzie oczekuje się tożsamości. Osiągalność idzie do mapy.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Anatomia wpisu mapy

Kluczem jest adres overlay zapisany jako ciąg w cudzysłowie, a wartością lista punktów końcowych, więc jedna tożsamość może mieć kilka wejść. Każdy punkt końcowy niesie host i port, a port musi odpowiadać temu, na czym druga strona naprawdę nasłuchuje. Domyślna wartość Nebula to UDP 4242, co jest punktem wyjścia, a nie obietnicą dotyczącą twojego wdrożenia.

Kilka punktów końcowych jest przydatnych, gdy latarnia ma więcej niż jedną drogę do środka, na przykład adres publiczny i adres prywatny dla hostów w tym samym segmencie. Klient próbuje ich po kolei, więc najbardziej niezawodny umieść jako pierwszy. Dla IPv6 ujmij adres w nawiasy kwadratowe przed dodaniem portu; pomyłka daje błąd parsowania wskazujący niewłaściwą linię.

Zły port daje ciszę zamiast błędu, bo UDP nie ma uścisku dłoni, którym mógłby odmówić. Dlatego warto sprawdzić format wpisu wobec referencji Nebula dla static_host_map a nie pamięci. Referencja obejmuje też listy punktów końcowych i zachowanie odświeżania DNS.

Bootstrap musi działać przed overlay

Nazwa DNS w mapie musi się rozwiązywać przez resolver, który host ma przed jakimkolwiek tunelem, czyli zwykły resolver systemowy. Sprawdź to z tej samej maszyny, przy starcie, z zatrzymanym overlay. Nazwa, która rozwiązuje się tylko przez własny DNS overlaya, nie może zainicjować overlaya. Ten sam test dotyczy trasy: reguła zapory, która pozwala na overlay, ale nie na pierwszą wymianę UDP, blokuje pierwszy pakiet.

Sprawdź port narzędziem UDP, zamiast zakładać, że jest otwarty. Potwierdź, że każde przekierowanie portu na drodze wskazuje właściwy host wewnętrzny i że istnieje droga powrotna. Jeśli nazwa hosta rozwiązuje się na kilka adresów, przetestuj każdy, bo klient może wybrać adres, którego nigdy nie sprawdziłeś.

Statyczne wpisy są wybierane bezpośrednio i nigdy nie pytają latarni. Dlatego błąd tutaj wygląda jak zwykły limit czasu bez udziału peera.

Co dzieje się po pierwszym uścisku dłoni

Gdy host dotrze do latarni, dowiaduje się o peerach i ich osiągalnych adresach bez kolejnych ręcznych wpisów. Hosty, które przemieściły się od ostatniego połączenia, stają się wykrywalne przez ten kanał. To nagroda za utrzymywanie ręcznej mapy w małym rozmiarze.

Hosty mogą też ogłaszać własne dodatkowe osiągalne adresy, i tak peer za znanym publicznym adresem pomaga innym go znaleźć. Te ogłoszenia są poznawane, a nie wpisywane do statycznej mapy.

Zachowanie odświeżania ma znaczenie dla punktów końcowych zapisanych jako nazwy DNS, bo rozwiązany adres może się zmienić, gdy proces nadal działa. Ustawienia Nebula kontrolują, jak odbywają się te wyszukiwania, w tym który resolver jest używany, więc czytaj je, zamiast zakładać domyślne ustawienie systemu. Na hoście, którego resolver zmienia się, gdy podnosi się tunel, błędne ustawienie może zamienić działający bootstrap w nazwę, która przestaje się rozwiązywać w połowie sesji. Przypięcie wyszukiwania do stabilnego resolvera jest często różnicą między niezawodnym overlay a przerywanym.

Gdy wykrywanie działa, a jeden peer nie

Jeśli latarnie są osiągalne i większość peerów się łączy, bootstrap nie jest problemem. Pozostała para albo nie znajduje użytecznej drogi do siebie, albo zawodzi ponad osiągalnością. Dodanie kolejnej pisowni adresu latarni nie naprawi żadnego z tych przypadków.

Sprawdź parę, zanim edytujesz mapę, na której już opiera się wszystko inne. Zmiana mapy zakłóca każdy host, więc to ostatnia rzecz, której się dotyka, a nie pierwsza.

Zacznij od certyfikatów tej samej instytucji, bo odrzucony uścisk dłoni może z daleka wyglądać jak nieosiągalny peer. Potem sprawdź, czy para może ustanowić bezpośrednią drogę i czy relay jest skonfigurowany dla sieci, które odmawiają bezpośredniego ruchu. Relay dodaje przeskok i zależność, ale to wspierana odpowiedź, a naprawianie drogi pary to inne zadanie niż naprawianie wykrywania.