Zaplanuj podsiedzi przed VPN między lokalizacjami: przenumeruj lub przetłumacz

Dwa biura używają oba 192.168.1.0/24, bo nikt nie zaplanował inaczej, a tunel ma to rozwiązać. Nie może: router nie może sprawić, by ten sam adres prywatny oznaczał dwa różne miejsca. Praca, która temu zapobiega, dzieje się przed wpisaniem pierwszego parametru tunelu.

Zinwentaryzuj każdy zakres, także te zapomniane

Zbierz sieci LAN, segmenty serwerów, pule klientów dostępu zdalnego, zakresy VPC w chmurze i wszelkie sieci kontenerów lub nakładkowe, do których hosty muszą dotrzeć. Pule klientów to te, o których ludzie zapominają, i zaskakująco często pokrywają się z zakresem biurowym, bo oba wybrano z tego samego ustawienia domyślnego. Uwzględnij sieć zarządzania i dowolny segment out-of-band.

Zapisz właściciela, bramę, cel i to, czy prefiks musi być osiągalny z drugiej lokalizacji. Prefiks, który nigdy nie musi przechodzić przez tunel, nie musi być unikalny, a wiedza o tym zmniejsza pracę przy przenumerowaniu.

IPv6 zrób osobno, ponieważ jego plan i nakładanie się są niezależne.

Porównuj prefiksy, a nie znane adresy

Dwie sieci z różnymi adresami hostów nadal mogą się nakładać, bo nakładanie się to cecha masek, a nie liczb, które ludzie pamiętają. 10.20.0.0/16 zawiera 10.20.30.0/24, niezależnie od tego, czy ktoś powie to na głos. Porównuj pełne pary prefiksów i sprawdzaj agregaty wobec mniejszych sieci w nich. Dlatego ta kontrola należy do arkusza kalkulacyjnego, a nie do czyjejś głowy.

Ta sama kontrola dotyczy własnej puli klientów VPN i każdego tłumaczonego zakresu, który planujesz wprowadzić, bo kolidujący tłumaczony zakres jest gorszy niż pierwotne nakładanie się.

Tabela prefiksów z maskami wystarczy; diagram bez masek nie.

Zdecyduj, co naprawdę musi przechodzić

Jedna lokalizacja może zawierać trzydzieści podsiedzi, podczas gdy jedna sieć usług wymaga dostępu zdalnego. Zacznij od tego wymagania i ogłaszaj tylko to, czego potrzebuje, bo mniejsze ogłoszenia i pasujące reguły dostępu łatwiej przejrzeć i trudniej przypadkiem rozszerzyć. Ogłaszanie każdego używanego zakresu prywatnego to nawyk, który zamienia tunel w most. Im węższe ogłoszenie, tym mniejszy promień rażenia przyszłego błędu.

Prywatny DNS musi zwracać adresy, do których docierają zamierzeni klienci, więc nazwa wskazująca na nieogłoszony lub nakładający się zakres pozostaje zepsuta nawet wtedy, gdy wyszukiwanie się powiedzie.

Napisz listę dostępu przed konfiguracją tunelu, a nie po tym, jak zawiedzie.

Przenumeruj lub przetłumacz i poznaj koszt

Przenumerowanie jednej sieci to zwykle najjaśniejsze długoterminowe rozwiązanie, które dotyka rezerwacji, urządzeń, DNS, reguł zapory i wszystkiego, co ma adres wpisany w konfigurację. Tłumaczenie zakresu dostępu jest alternatywą, gdy przenumerowanie jest niepraktyczne, i kosztuje tożsamość źródła oraz klasę protokołów, które osadzają adresy w ładunku. Wybierz jedno i dokończ, bo na wpół przenumerowana sieć jest gorsza niż każda z opcji.

Cokolwiek wybierzesz, udokumentuj zarówno adres pierwotny, jak i prezentowany, bo każda późniejsza rozmowa o rozwiązywaniu problemów potrzebuje obu.

Obejście bez drogi powrotnej nie jest obejściem.

Użyj macierzy tras jako testu akceptacyjnego

Zakończ macierzą: prefiks lokalny, prefiks zdalny, dozwolona usługa i brama powrotna. Ta tabela jest testem akceptacyjnym, gdy tunel wstaje, i jest też dokumentem, który przeczyta następny inżynier. Testuj z prawdziwych hostów w wybranych podsiedziach, a nie z bram.

Ping między adresami tunelu dowodzi, że tunel istnieje, i niczego o planie adresów za nim.

Trzymaj macierz razem z konfiguracją tunelu, a następne dodanie lokalizacji zacznie się od danych, a nie od pamięci. Gdy plan istnieje, przewodnik strongSwan po przekazywaniu obejmuje stronę bramy.