Dwie sieci LAN w NetBird: które peery routują i kto może rozmawiać

Stacja robocza w zachodniej sieci LAN otwiera przeglądarkę, wpisuje adres aplikacji we wschodniej sieci LAN i czeka, aż upłynie limit czasu. Każdy ekran NetBirda mówi, że peery są połączone, co jest prawdą i nie ma znaczenia: bycie w jednej sieci nakładkowej to nie to samo co trzymanie dwóch lokalnych podsieci w jednej sieci. Poniższa wędrówka zaczyna się na tej stacji roboczej i kończy żądaniem, którego projekt świadomie odmawia, a każdy przystanek to coś, co odczytuje się z urządzenia, a nie zgaduje. Spodziewaj się, że brakującym elementem jest trasa lub polityka, a nie nakładka.

Najpierw odczytaj awarię ze stacji roboczej

Przed otwarciem konsoli zarządzania ustal, co stacja robocza rzeczywiście wysyła. Jej własna tablica routingu decyduje, czy pakiet trafi do bramy lokalizacji, do interfejsu lokalnego czy donikąd, i ta decyzja jest widoczna bez żadnego narzędzia nakładkowego. Maszyna bez trasy do odległego prefiksu zawiedzie, niezależnie od tego, jak zdrowa wygląda lista peerów. Zakres nakładki i własny prefiks lokalizacji to różne przestrzenie adresowe, a rejestracja skonfigurowała tylko jedną z nich.

Następnie oddziel rozwiązywanie nazw od osiągalności, bo przeglądarka zgłasza oba jako ten sam limit czasu. Powtórz żądanie po adresie z maszyny z klientem NetBird, a potem ze zwykłej stacji roboczej bez niego. Jeśli maszyna zarejestrowana sobie poradzi, a zwykła nie, luka jest w routingu lokalnym; jeśli obie zawiodą, czytaj dalej, zanim zmienisz trasę.

Wybierz jednego peera routującego na lokalizację

Peer routujący to host, który reprezentuje swoją sieć LAN w nakładce, więc wybierz maszynę Linux ze stabilną osiągalnością podsieci, a nie czyjąś stację roboczą na biurku. Zarejestruj ją zwykłą procedurą i umieść w grupie nazwanej według roli, bo zasób sieciowy i polityka będą się oba odwoływać do tej grupy. Jeden przedstawiciel na lokalizację pozostaje czytelny; tłum ochotników ogłaszających ten sam prefiks zamienia każde późniejsze pytanie w sesję debugowania. Adres peera w segmencie lokalnym liczy się tak samo jak jego tożsamość w nakładce, bo ten adres staje się następnym skokiem podawanym każdemu zwykłemu urządzeniu.

Zapisz plan, zanim dotkniesz konsoli, bo nazwy i prefiksy to miejsce, w którym te projekty dryfują: prefiks, brama, adres peera i grupa, dla każdej lokalizacji. Zachód to 10.52.0.0/24 obsługiwany przez 10.52.0.5, a wschód to 10.63.0.0/24 obsługiwany przez 10.63.0.5; dwie grupy to west-routers i east-routers, i żaden prefiks nie może nakładać się na drugi, na zakres nakładki ani na inny trasowany cel.

Utwórz zasób, zostaw maskowanie włączone

We wdrożonym panelu utwórz jeden zasób sieciowy na lokalizację i podłącz do niego grupę peerów routujących tej lokalizacji. Zasób to prefiks, a grupa to host, który za niego odpowiada, i oba muszą istnieć, zanim cokolwiek zostanie ogłoszone. Potwierdź, że wdrożona wersja samodzielnie hostowana ma w ogóle przepływ pracy Sieci, bo starszy interfejs z podobnie nazwanym obiektem trasy to inna funkcja.

Zostaw maskowanie włączone. Przewodnik NetBirda po połączeniach między lokalizacjami wymaga go w tym układzie, a wyłączenie go, aby każdy oryginalny adres pozostał widoczny, nie jest tym samym projektem o jeden skok mniej; zmienia to, co widzą kontrole źródła i polityki nakładki. Skutek warto powiedzieć wprost: usługa odbierająca zapisuje jako źródło peera routującego, a nie pojedynczą stację roboczą. Jeśli lista dozwolonych lub audyt tej usługi oczekuje adresów stacji roboczych, albo zmienia się oczekiwanie, albo tożsamość musi być wymuszona na granicy lokalizacji przed tłumaczeniem.

Upoważnij inicjatorów, nie prefiksy

Trasa czyni adres osiągalnym, a polityka decyduje, kto może go użyć; to dwa osobne obiekty z osobnymi właścicielami. Napisz politykę od obciążenia roboczego wstecz: która grupa inicjuje, na który zasób celuje i której usługi TCP potrzebuje. Sieć, która ogłasza oba prefiksy każdemu zarejestrowanemu peerowi, stworzyła osiągalność i niczego nie rozstrzygnęła.

Potem przeczytaj, co jeszcze jest już dozwolone, bo wąska nowa reguła nie odwołuje szerokiej starej, która stoi nad nią. Gdy wschód też musi zaczynać połączenia do zachodu, zapisz ten kierunek jako własną politykę; ruch powrotny sesji otwartej przez zachód to inne pytanie niż zezwolenie na nowe sesje na wschód. Jeśli tylko niektóre zachodnie stacje robocze mają docierać do wschodniej aplikacji, wybierz je na granicy lokalizacji przed tłumaczeniem i zachowaj własne uwierzytelnianie aplikacji. Peer routujący przenosi ruch LAN jako całą lokalizację, a nie jako tożsamość nakładki na użytkownika, więc rozliczanie na użytkownika musi pochodzić skądinąd.

Naucz każdą bramę następnego skoku, potem sprawdź odmowę

Zwykłe urządzenia nigdy nie widzą nakładki, więc ich własna brama potrzebuje trasy statycznej kierującej odległy prefiks na adres LAN peera routującego. To krok, który ludzie pomijają, bo wszystko widoczne w NetBirdzie już działa, a zwykłe stacje robocze wciąż kończą się limitem czasu. Brama zachowuje swoją trasę domyślną tak, jak była; ten prefiks to dodatek, nie zamiana.

Oba opisy trasy należą do konfiguracji bramy każdej lokalizacji, a nie do nadpisania na hoście. Oba są zwykłymi trasami statycznymi i żadna nie dotyka trasy domyślnej:

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

Sprawdź aplikacją, której projekt naprawdę potrzebuje, ze zwykłej stacji roboczej, i zapisz trzy rzeczy: następny skok wybrany po stronie nadawcy, dopasowaną politykę i adres źródłowy zapisany przez usługę. Sprawdź też odmowę, bo projekt, który nigdy niczego nie odrzucił, ma nieznane krawędzie, a odmowa jest jedynym dowodem, że pracę wykonuje polityka, a nie routing. Gdy wschód też musi inicjować, rozpocznij nowe połączenie z tej strony, zamiast zakładać, że drugi kierunek podąży. Zaplanuj też restart, aktualizację i wymianę peera routującego, bo jeden host stał się zależnością lokalizacji.

Prywatne nazwy wymagają własnego projektu resolvera, bo osiągalność nie tworzy rekordów DNS, a działająca ścieżka IP z zepsutą nazwą czyta się dokładnie jak zepsuta ścieżka. Jeśli peer routujący działa w sieci chmurowej, przejrzyj też reguły przekazywania i zapory dostawcy, bo rejestracja ich nie unieważnia. Trzymaj obserwacje z testu obok planu, bo następna osoba, która to zdebuguje, będzie chciała dopasowanej polityki i zapisanego adresu źródłowego, a nie opisu topologii.