Przełączanie awaryjne VPN: gdy droga powrotna zostaje w starym tunelu

Tunel zapasowy wstaje, główny pada, a aplikacja nadal kończy się przekroczeniem czasu. W obu lokalizacjach stan tunelu wygląda zdrowo, i właśnie to dezorientuje. Przełączenie, które przenosi żądania na zapas, ale zostawia odpowiedzi na starej drodze, nie jest przełączeniem. Poniższa instrukcja testuje drogę powrotną, nie tylko uścisk dłoni.

Najpierw zanotuj trasy na obu końcach; widok z jednej lokalizacji nie pokaże asymetrycznej drogi. To także krok najczęściej pomijany pod presją czasu.

Zanotuj trasy obu lokalizacji przed testem

Dla każdego chronionego prefiksu zapisz trasę główną, trasę zapasową i preferencję, która wybiera między nimi. Uwzględnij bramę LAN za każdym punktem końcowym VPN, ponieważ punkt końcowy rzadko jest ostatnim skokiem.

Metryki statyczne, śledzone trasy i routing dynamiczny wyrażają przydatność na różne sposoby. Wiedz, którego używa twój projekt i co jest potrzebne, aby alternatywa stała się aktywna. Zapisz warunek obok trasy, na przykład niższą metrykę, dopóki test nie zawiedzie.

Zrób to w obu lokalizacjach. Zapas preferowany po jednej stronie i ignorowany po drugiej tworzy dokładnie tę asymetrię, której próbujesz uniknąć.

Obserwuj żądania i odpowiedzi w każdej fazie

Użyj nieszkodliwej dozwolonej aplikacji i obserwuj trzy fazy: normalną, awarię głównej drogi i przywrócenie. W każdej fazie zanotuj, który tunel niesie żądanie, a który odpowiedź. Osiągalny adres peera nie dowodzi, że chroniona droga aplikacji działa. Zapisuj w obu lokalizacjach, aby jednokierunkowy przepływ był widoczny.

Jeśli żądania się przesuwają, a odpowiedzi nie, sprawdź trasę zdalnej lokalizacji do prefiksu klienta i jej preferencję dla zapasu. To decyzja routingu, a nie awaria tunelu.

Po teście przywróć pierwotny stan i potwierdź, że główna droga znów jest preferowana. Przywrócona główna droga, która nie jest preferowana, to niedokończony projekt przełączania.

Zarządzaj stanem sesji, gdy zmienia się brama

Zapory i NAT mogą trzymać stan połączenia na jednej bramie, a zmiana drogi na inną bramę go nie przenosi. Niektóre aplikacje łączą się ponownie same; inne zawodzą, dopóki sesja nie zostanie odtworzona. Jeśli zapas zmienia źródło publiczne lub przetłumaczony adres prywatny, reguły dostępu zdalnego też mogą zareagować. Dokumentuj każde oczekiwane ponowne uruchomienie sesji, zamiast obiecywać przełączanie bez przerwy.

Zachowaj stabilne adresowanie tam, gdzie wymaga tego aplikacja. Projekt przełączania, który zmienia adres źródłowy dla każdej sesji, jest wyborem projektowym i powinien zostać zapisany. Ten wybór określa, jak dużą przerwę użytkownicy faktycznie zauważą.

Testuj aplikację utrzymującą długą sesję, nie tylko nowe żądanie.

Przywróć główną drogę i sprawdź flapping

Potwierdź, że ogłoszenia tras lub preferencje stabilizują się bez oscylacji. Flappingująca główna droga może być bardziej uciążliwa niż wyraźna awaria, ponieważ każde przejście resetuje stan.

Utrzymuj dostęp do administracji bramy przez drogę odzyskiwania, aby sam test nie zamknął cię na zewnątrz. Zanotuj fazy, zaobserwowane drogi i czas odzyskiwania; ten zapis czyni następne przełączenie przewidywalnym. Notatki strongSwan o przekazywaniu są przydatne, gdy punkty końcowe to hosty Linux.