Kto naprawdę odpowiada na dedykowanym adresie VPN?

Adres, który leży nieużywany w puli organizacji, nie jest nasłuchiwaczem, a dodanie go do zapory nie tworzy żadnego. Coś musi zakończyć IKE na tym adresie, a mechanizm różni się w zależności od tego, czy adres należy do bramy, czy tłumaczy go urządzenie wyżej w torze. To ścieżka pakietu odróżnia oba przypadki i ona decyduje, której funkcji platformy potrzebujesz, zanim ktokolwiek otworzy wniosek o zmianę. Najpierw zamodeluj ścieżkę, potem wybieraj.

Ścieżka pakietu za adresem

Partner wysyła IKE na adres, który otrzymał, przez UDP 500 albo UDP 4500, gdy w grę wchodzi przechodzenie przez NAT. Urządzenie trzymające ten adres na ścieżce albo odbiera datagram lokalnie i odpowiada na niego, albo przekazuje go dalej w inne miejsce. To jedyne dwie możliwości, a wszystko pozostałe w tym artykule wynika z tego, która jest prawdziwa.

Odbiór lokalny oznacza, że na tym urządzeniu istnieje gniazdo powiązane z tym adresem. Przekazywanie oznacza, że datagram jest przepisywany i wysyłany dalej do innego punktu końcowego, który wtedy ma gniazdo. Reguła zapory zezwalająca na UDP 500 nie mówi nic o tym, która z tych dwóch rzeczy się dzieje.

Zapisz rekord, zanim czegokolwiek dotkniesz: adres, z którym łączą się partnerzy, sposób dostarczania go przez sieć nadrzędną, lokalny interfejs lub logiczny punkt końcowy, który go odbiera, oraz proces odpowiadający na IKE. Cztery wiersze i każdy można sprawdzić. Gdy któryś jest nieznany, ta nieznana jest pracą projektową, a nie szczegółem wdrożenia do rozstrzygnięcia później. Uzupełnianie ich po zatwierdzeniu wniosku o zmianę to sposób, w jaki reguła tłumaczenia trafia na niewłaściwe urządzenie.

Model A: brama posiada adres

W pierwszym modelu brama sama trzyma adres, jako adres dodatkowy na istniejącym interfejsie, jako adres na dedykowanym interfejsie albo jako loopback, który platforma obsługuje jako punkt końcowy tunelu. To trzy różne funkcje o trzech różnych ścieżkach konfiguracji, a platforma obsługująca jedną może nie obsługiwać pozostałych.

Przed projektowaniem wokół tego potwierdź, że platforma i wydanie obsługują dokładnie taki układ. Blok routowany, dodatkowy adres na interfejsie i punkt końcowy loopback nie są wymienne, a dokumentacja jednego wydania nie obiecuje, że następne zachowa się tak samo.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

Dowodem jest gniazdo nasłuchujące. Jeśli nic nie jest powiązane z adresem, brama nie jest terminatorem niezależnie od tego, co mówi tablica routingu, a przechwycenie pakietów pokaże datagramy przychodzące bez niczego, co na nie odpowiada.

Nie umieszczaj drugiego interfejsu w podsieci, która już istnieje gdzie indziej w topologii, i nie zakładaj, że platforma to rozwiąże. Nakładające się podsieci interfejsów dają niejednoznaczny wybór źródła, a na wielu platformach całkowitą odmowę konfiguracji.

Model B: urządzenie wyżej w torze tłumaczy adres

W drugim modelu zapora wyżej w torze trzyma dedykowany adres i przekazuje ruch do innej bramy VPN. To tłumaczenie adresu docelowego ze ścieżką powrotną i całkowicie poprawny projekt, dopóki jest tak udokumentowany.

Nie jest natomiast dowodem, że urządzenie wyżej w torze uzyskało lokalne gniazdo VPN. Tłumaczenie przekazuje pakiety; nie czyni górnego pudełka odpowiadającym na IKE. Jeśli reguła wyżej w torze zostanie usunięta albo jej ścieżka powrotna się zerwie, VPN zatrzyma się, choć brama jest zdrowa, a jej własne nasłuchiwacze nietknięte.

Zapisz oba adresy: ten, z którym łączą się partnerzy, i ten, który brama faktycznie widzi. Potem zapisz transport i ścieżkę powrotną, bo tłumaczenie działające dla UDP 500, ale nie dla kapsułkowanego ESP, połączy się i potem nie zdoła przenosić ruchu, co jest mylącą usterką przy późniejszym debugowaniu.

Tożsamość to nie adres zewnętrzny

IPsec oddziela punkt końcowy tunelu od ruchu, który chroni, a architektura trzyma te decyzje w różnych miejscach. Zmiana adresu, z którym łączą się partnerzy, nie zmienia automatycznie tego, które prefiksy wewnętrzne są dozwolone, które trasy są instalowane ani do których zasobów sesja może dotrzeć.

Uwierzytelniona tożsamość jest znowu osobna. IKEv2 niesie ładunek tożsamości i wymianę uwierzytelniania, które nie muszą odpowiadać zewnętrznemu adresowi pakietu, i właśnie dlatego przetłumaczony projekt nadal może uwierzytelniać się poprawnie.

Ta niezależność jest użyteczna i jednocześnie pułapką. Dwie nazwy DNS rozwiązujące się na jednego zwykłego nasłuchiwacza nie wybierają różnych backendów VPN, a certyfikat nazywający jedną tożsamość nie zadowoli partnera oczekującego innej. Potwierdź, co waliduje partner, zanim założysz, że decyduje o tym sam adres.

Zaakceptuj projekt, obserwując jedno połączenie

Sprawdź, gdzie faktycznie trafia nowe autoryzowane połączenie, która tożsamość odpowiada i który przepływ prywatny jest następnie dozwolony. Trzy obserwacje, trzy różne warstwy, a udane publiczne zapytanie o adres nie testuje żadnej z nich.

Zachowaj też przypadek negatywny: partnera, którego nie należy akceptować, albo prefiks wewnętrzny, do którego nie powinno być dostępu, zweryfikowane po zmianie. Rekord zapisany na początku jest tym, co umożliwia ten test bez odtwarzania projektu z pamięci.

Sensem tego wszystkiego jest pozwolić właścicielowi sieci wybrać obsługiwaną metodę przydziału, zamiast opierać się na ogólnym twierdzeniu, co każda zapora potrafi zrobić z dodatkowym adresem. To właśnie to twierdzenie jest miejscem, w którym te projekty się psują, bo brzmi wiarygodnie na każdej platformie i w ogólności nie jest prawdziwe na żadnej. Rekord z czterech wierszy rozstrzyga to dla Twojej platformy w dziesięć minut.