Filtry latarni Nebula a firewall: co blokuje każdy z nich

Spojrzyjcie na uścisk dłoni Nebula z niewłaściwej strony, a oba mechanizmy wydadzą się wymienne. Jeden decyduje, które adresy węzeł zgłasza latarni i których adresów zdalnych spróbuje; drugi decyduje, co może przejść, gdy tunel już istnieje. Filtr może zatrzymać połączenie, zanim zostanie oceniona jakakolwiek reguła firewalla, a reguła firewalla nie może ożywić punktu końcowego, który usunęło wykrywanie. Obie warstwy odpowiadają na różne pytania, a kolejność ich działania jest kluczem.

Prześledźcie jedno połączenie przez cztery etapy: ogłoszony adres lokalny, rozważany zdalny punkt końcowy, uścisk dłoni i ruch w warstwie nakładkowej. Każdy etap ma własną konfigurację i własny podpis awarii.

Zacznijcie od adresu lokalnego, który ogłasza węzeł

local_allow_list filtruje lokalne adresy tego hosta, zanim zostaną zgłoszone latarniom. Wpisy mogą być zakresami adresów, a konfiguracja obsługuje także wzorce nazw interfejsów. Jest to przydatne, gdy host ma mosty kontenerów lub dodatkowe interfejsy tunelu, które nie powinny stać się punktami końcowymi partnerów.

Przejrzyjcie interfejsy hosta i zapytajcie, do których zdalny partner naprawdę może dotrzeć. Adres mostu Docker jest lokalny dla tego hosta i bezużyteczny dla partnera w innej sieci. Ogłaszanie go marnuje wykrywanie i może wysłać partnera pod adres, który nigdy nie odpowiada. Wszystko, do czego partner nie może kierować, jest szumem w odpowiedzi latarni.

Wąska lista dozwolonych jest tutaj bezpieczniejsza niż szeroka lista blokowanych. Jeśli występują tylko wpisy dozwolone, nieokreślona reszta jest wykluczona; dodanie później wpisu blokady zmienia logikę domyślną i wymaga własnego przeglądu. Ta zmiana zasługuje na drugie spojrzenie na wartość domyślną.

Następnie obserwujcie wybór zdalnego punktu końcowego

remote_allow_list filtruje adresy, które ten host rozważy dla zdalnego partnera podczas uścisku dłoni. Dotyczy to adresu warstwy podstawowej, a nie adresu warstwy nakładkowej, którego partner użyje po podniesieniu tunelu.

Prywatny zakres może być całkowicie użyteczny w współdzielonej sieci biurowej i bez znaczenia, gdy oba hosty znajdują się w niepowiązanych sieciach, które obie używają 10.0.0.0/8. Filtr pozwala preferować trasę routowalną i ignorować zbieg okoliczności.

Gdy partner nie może się połączyć, porównajcie próbowany adres z regułą, która do niego pasuje. Włączcie dzienniki uścisku dłoni i odczytajcie wybrany adres zdalny; wiersz dziennika nazywa punkt końcowy, który przetrwał filtrowanie, co jest użyteczniejsze niż lista adresów, które posiada partner.

Filtr nazw interfejsów po stronie ogłaszającej może usunąć punkt końcowy, zanim strona odbierająca go zobaczy. Sprawdźcie oba węzły, gdy zawodzi tylko jeden kierunek.

Po uścisku dłoni obowiązują reguły dostępu warstwy nakładkowej

Reguły firewalla Nebula działają wewnątrz warstwy nakładkowej, po zestawieniu tunelu. Dopasowują hosty, grupy, porty i protokoły oraz decydują, czy pakiet może wejść do lokalnego hosta albo go opuścić. Nie wybierają punktu końcowego w warstwie podstawowej.

Ten rozdział wyjaśnia częstą błędną diagnozę. Operator dodaje regułę firewalla dla portu i nadal nie może się połączyć, ponieważ filtr latarni usunął jedyny osiągalny punkt końcowy. Inny operator otwiera filtr adresów i nadal nie dociera do usługi, ponieważ firewall warstwy nakładkowej odrzuca port.

Czytajcie awarię na właściwej warstwie. Uścisk dłoni, który nigdy się nie kończy, wskazuje na wykrywanie, filtrowanie punktów końcowych lub ścieżkę sieci. Zakończony uścisk dłoni, po którym połączenie z usługą jest odrzucane lub porzucane, wskazuje na firewall warstwy nakładkowej lub aplikację.

Czytajcie wartość domyślną przy mieszaniu zezwolenia i blokady

Konfiguracja latarni obsługuje listy tylko zezwalające, tylko blokujące i mieszane, a wartość domyślna dla nieokreślonej reszty różni się między tymi formami. Lista mieszana wymaga jawnej wartości domyślnej dla rodziny adresów; założenie, że reszta zachowuje się jak poprzednia konfiguracja, jest drogą, którą działający punkt końcowy cicho znika.

lighthouse:
  local_allow_list:
    interfaces:
      docker0: false
  remote_allow_list:
    192.168.0.0/16: true
    default: false

Traktujcie wartość domyślną jako część reguły, a nie jako tekst szablonu. Jeśli domyślną wartością rodziny jest blokada, każdy niewymieniony adres jest wykluczony, w tym nowy zakres biurowy dodany po napisaniu konfiguracji.

Zapiszcie, które adresy miały być osiągalne, i testujcie z obu stron. Filtr, który działa dla jednej pary partnerów, może zawieść dla innej pary, której jedyna wspólna ścieżka używa adresu wykluczonego przez listę.

Użyjcie przekaźnika, gdy żaden bezpośredni punkt końcowy nie jest osiągalny

Jeśli każdy kandydat na punkt końcowy jest odfiltrowany lub nieosiągalny, odpowiedzią nie jest szersza lista dozwolonych, która ponownie przyjmuje adresy, którym nie ufacie. Konfiguracja przekaźnika Nebula zapewnia alternatywną ścieżkę partnera, gdy bezpośrednia łączność nie jest wykonalna.

Przekaźnik rozwiązuje transport i wykrywanie, a nie autoryzację, i nie poszerza firewalla. Firewall warstwy nakładkowej nadal decyduje, których usług można używać, a przekaźnik nie zamienia filtrowania latarni w mechanizm kontroli dostępu.

Przetestujcie ścieżkę przekaźnika z wyłączonymi bezpośrednimi punktami końcowymi i potwierdźcie, że zamierzona usługa nadal działa, a niezamierzona nie. Ten jeden test oddziela naprawę transportu od zmiany polityki i utrzymuje obie warstwy uczciwymi.