Zaplanuj prywatne zakresy adresów VPN, zanim witryny się zderzą

Dwie witryny, które obie używają 192.168.1.0/24, mogą każda dotrzeć do internetu i mimo to nie dotrzeć do siebie. Brama nie zgłasza błędu; instaluje jedną trasę dla tego prefiksu i wysyła każdy pakiet do tego partnera, który zażądał jej pierwszy. Nic w uzgadnianiu, liście szyfrów ani metryce interfejsu nie mówi, który partner się myli. Planowanie adresów to ta część projektu, która rozstrzyga to, zanim ktokolwiek się połączy.

Zinwentaryzuj każdą przestrzeń, która musi być osiągalna

Zapisz zakresy, które trzeba routować, nie tylko te, które konfigurujesz. To znaczy sieci LAN witryn, pule klientów VPN, podsieci w chmurze, sieci zarządzania i poza pasmem, segmenty laboratoryjne oraz sieci, z których użytkownicy zwykle łączą się z domu. Router konsumencki dostarczany jako 192.168.1.0/24 nie jest hipotetyczny, a ten sam prefiks pojawia się w hotelach i centrach konferencyjnych. Inwentarz to tabela prefiksu, właściciela i celu, i jest jedynym artefaktem, który powstrzymuje przed wydaniem tego samego zakresu dwa razy.

Dodaj prefiksy, których oczekujesz w ciągu najbliższego roku, bo plan obejmujący tylko dziś zawodzi w pierwszej nowej witrynie. Oznacz w każdym wierszu, kto może go zmienić, nie tylko kto go posiada.

To ponowne użycie czyni to trudnym: przestrzeń prywatna jest skończona i każda organizacja uważa 10.0.0.0/8 za swoją. Plan nie może obiecać, że żadna przyszła sieć gości nie wyląduje na jednym z twoich prefiksów, więc projekt musi powiedzieć, co się dzieje, gdy tak się stanie. Większość pracy wykonują dwie reguły. Umieść pule klientów w jednym ciągłym bloku, który potrafisz podsumować, i nigdy nie przydzielaj zakresu, który inny zespół już routuje. Wszystko inne to rejestr, który ktoś utrzymuje na bieżąco.

Dlaczego nakładanie pokonuje tablicę routingu

Trasa to prefiks plus następny skok, a przekazywanie wybiera najdłuższy pasujący prefiks. Gdy dwa partnerskie węzły żądają oba tego samego 192.168.1.0/24, tablica trzyma dla niego jeden wpis, więc ruch obu witryn wychodzi tym samym tunelem. Druga witryna nie jest źle skonfigurowana; jest nieosiągalna, bo pierwsza odpowiada za te same adresy. Żadna metryka nie może ich rozdzielić, bo dopasowanie następuje, zanim metryki są brane pod uwagę.

Awaria jest asymetryczna i łatwo ją błędnie odczytać. Hosty witryny A docierają do bramy i niektórych usług, podczas gdy hosty witryny B nie odpowiadają na nic, a dziennik pokazuje zdrowy tunel w obu kierunkach. Ten wzorzec to kolizja adresów, a nie usterka uwierzytelniania lub zapory, i potwierdzenie go wymaga jednego zrzutu tablicy porównanego z inwentarzem.

Rozmiar puli klientów i zakresów witryn ustal świadomie

Pula klientów VPN to zakres, z którego brama wydaje po jednym adresie, więc jej rozmiar ogranicza współbieżność. /24 mieści 254 użyteczne adresy, co jest hojne dla małego zespołu i ciasne dla oddziału uruchamiającego kontenery; /22 nic nie kosztuje dodatkowo w przestrzeni prywatnej i usuwa spór. Utrzymuj pulę ciągłą i z dala od każdej sieci LAN witryny, aby trasa zbiorcza do klientów nigdy nie połknęła witryny. Zarezerwuj zakres nawet wtedy, gdy pula jest pusta, bo niezapisany zakres to ten, który przydzieli następny inżynier.

Witryny dostają zakresy dobrane do oczekiwanych hostów plus wzrost, wyrównane na granicy, która czysto się sumuje. Celowe luki między przydziałami nic nie kosztują i kupują miejsce na późniejszą agregację.

Następnie sprawdź kierunek, o którym ludzie zapominają: drogę powrotną. Każdy router witryny potrzebuje trasy do puli klientów, a koncentrator potrzebuje trasy do każdego obsługiwanego prefiksu witryny. Schludna tablica prefiksów bez drogi powrotnej do puli wciąż jest zepsutym projektem, a objawem jest połączenie jednokierunkowe, które na nic nie odpowiada. Trzymaj oba kierunki w tej samej tablicy i przeglądaj ją za każdym razem, gdy dodawana jest witryna.

Tłumaczenie i przenumerowanie rozwiązują różne problemy

Gdy nakładanie już istnieje, są dwie uczciwe opcje i jedna nieuczciwa. Przenumerowanie usuwa kolizję trwale i kosztuje okno serwisowe oraz każdy zapomniany, twardo zakodowany adres. Tłumaczenie adresów odwzorowuje prywatny zakres jednej strony w inny zakres na krawędzi tunelu, co zostawia obie witryny nietknięte, ale dodaje stan, psuje protokoły osadzające adresy i utrudnia czytanie dzienników. Nieuczciwą opcją jest trasa hosta do jednego serwera, która przechodzi jeden test i zawodzi we wszystkim innym.

Wybieraj według kontroli i czasu życia. Witryna, którą posiadasz i możesz zaplanować, należy do ścieżki przenumerowania; sieć partnerska, której nie możesz dotknąć i która służy jednej aplikacji, jest kandydatem do tłumaczenia z udokumentowanym mapowaniem. Zapisz to mapowanie, bo tłumaczenie istniejące tylko w pliku konfiguracyjnym znika w momencie, gdy plik zostaje zastąpiony.

Testuj ze strony zdalnej przed wdrożeniem

Testuj z sieci, która nie hostuje bramy, bo własna sieć LAN bramy ukrywa większość błędów routingu. Podłącz klienta za zwykłym routerem domowym, a następnie dotrzyj do usługi w każdej witrynie i jednej w puli klientów. Przetestuj też kierunek odwrotny, z hosta witryny do klienta, bo drogi powrotne zawodzą niezależnie. Test, który tylko pinguje bramę, dowodzi, że tunel działa, i niczego więcej.

Trzymaj zakresy, właścicieli i mapowania tłumaczeń w jednym wspólnym rejestrze, który następna witryna czyta przed przydzieleniem czegokolwiek. Przeglądaj go przy dodawaniu witryny i traktuj nieudokumentowany zakres jako defekt, a nie niespodziankę.

Rejestr jest wynikiem. Plan żyjący w pamięci trzech osób zawodzi za pierwszym razem, gdy jedna z nich jest na urlopie, a nakładanie znalezione w produkcji kosztuje więcej, niż kosztowałaby tabela.