Dwie bramy IPsec bez wspólnego IP: co naprawdę robi przełączenie awaryjne

Zabij bramę A w trakcie spotkania i obserwuj, jak tunel wraca przez B minutę później; połączenie działa, rozmowa wideo może nie. To uczciwy kształt zimnego przełączenia awaryjnego między dwiema bramami IPsec z niezależnymi adresami. Klient ponownie wybiera punkt końcowy i buduje nową relację, co przywraca osiągalność bez przenoszenia stanu kryptograficznego starej sesji. Prześledzenie sekwencji jasno pokazuje, które obietnice projekt może dotrzymać.

Ustawmy scenę: dwa adresy, żadnego pływającego IP

Brama A odpowiada pod jednym osiągalnym adresem, a brama B pod innym. Klient ma zatwierdzony sposób wyboru B, gdy A zniknie, i nie ma wspólnego adresu zewnętrznego, którego domagałyby się obie bramy. W tym projekcie wirtualne IP oznacza właśnie ten wspólny punkt wejścia, a nie adres wewnętrzny przydzielony klientowi dostępu zdalnego.

Ta definicja ma znaczenie, bo oba pomysły mieszają się w zgłoszeniach, a naprawa jednego nie jest naprawą drugiego. Zgłoszenie, że wspólne wejście nie poszło za bramą, opisuje jeden projekt. Zgłoszenie, że laptop utracił adres wewnętrzny, opisuje dzierżawę klienta. Różni właściciele, różne logi, różne naprawy.

Przejdźmy przez awarię: wykryć, potem wybrać ponownie

Najpierw coś zauważa, że A przestała odpowiadać. Może to być wykrywanie martwego partnera na warstwie tunelu, protokół routingu wycofujący ścieżkę albo limit czasu aplikacji, który w końcu wymusza ponowne połączenie. Każdy ma inną skalę czasu, a najwolniejszy zwykle decyduje, jak długo czekają użytkownicy.

Potem klient wybiera B przez mechanizm, który obsługuje wdrożenie: drugi skonfigurowany punkt zdalny, nazwę DNS rozwiązywaną na zdrowy adres albo routing, który teraz preferuje inną ścieżkę. Wybór jest krokiem polityki i musi istnieć przed awarią, inaczej zdarzy się przypadkiem.

Co B może, a czego nie może odziedziczyć

B może dzielić z A szablon konfiguracji, urząd certyfikacji i politykę uwierzytelniania. Nie może odziedziczyć aktywnych asocjacji bezpieczeństwa. Klucze sesji, indeksy parametrów bezpieczeństwa i stan sekwencji należą do relacji, którą ustanowiły A i klient, a B nie ma żadnego z nich.

Przenoszenie tego stanu między bramami to prawdziwy problem inżynierski, dlatego dokumentacja strongSwan dotycząca wysokiej dostępności traktuje to jako projekt klastra, a nie flagę konfiguracji. Konkretna recepta klastra nie jest ogólną odpowiedzią dla sieci w chmurze, a kopiowanie jej bez wspierającej infrastruktury kupuje złożoność zamiast ciągłości.

Ustanowienie nowej relacji

Po wybraniu B klient wykonuje nową wymianę IKE: nowe wartości nonce, nowe wartości Diffie-Hellman, nowe identyfikatory powstałych asocjacji. Uwierzytelnianie odbywa się ponownie w B. Jeśli projekt opiera się na poświadczeniach maszyny, ponowne połączenie może być bez nadzoru; jeśli wymaga czynnika ludzkiego, ktoś musi być obecny, aby przełączenie się zakończyło.

Zdefiniuj to doświadczenie użytkownika przed awarią, nie w jej trakcie. Powiedz jasno, co zrobi klient, jak długo będzie próbował i co pokaże, gdy się podda, bo różnica między minutą ponownego połączenia a telefonem do wsparcia to zwykle dokumentacja i przetestowany profil.

Zachowanie tego samego adresu wewnętrznego pomaga aplikacjom oczekującym stabilnej tożsamości lokalnej, ale nie zachowuje ich sesji. Powiązania NAT wygasają, połączenia TCP są resetowane, a wszystko z własnym limitem czasu samo decyduje, czy ponowić próbę.

Dwa tunele równolegle to inny projekt

Uruchamianie obu tuneli jednocześnie jest poprawnym wzorcem, gdy obsługują go obie bramy i projekt routingu. Wtedy wybór trasy wybiera aktywną ścieżkę, a ścieżka powrotna musi się zgadzać, inaczej ruch wychodzi przez jedną bramę i wraca przez drugą bez stanu, który by go dopasował.

Nakładające się polityki tuneli same nie tworzą uporządkowanego przełączenia. Tworzą dwóch kandydatów i coś musi między nimi zdecydować deterministycznie: metryka routingu, priorytet polityki albo wyraźna preferencja w kliencie.

Jakąkolwiek formę wybierzesz, zapisz umowę: jak wykrywana jest awaria, jak wybierany jest wariant zapasowy, jakiego uwierzytelniania wymaga i ile ma trwać ponowne połączenie. Wspólne IP może uprościć wykrywanie, ale nie jest synonimem stanu ciągłego, a dostępność i tak jest projektem.