Failover WAN: co dzieje się z otwartymi połączeniami przy przełączeniu łącza

Failover WAN przełącza ruch na inny dostęp do internetu po wykryciu awarii. Działająca trasa nie oznacza jednak automatycznego zachowania otwartych połączeń. Decydują adresy widoczne na zewnątrz, stan routera, protokół transportowy i sposób wznawiania pracy aplikacji.

Typowy przypadek w tym artykule to dwa niezależne łącza z różnymi publicznymi adresami IPv4 i NAT. NAT zamienia adresy lokalne na publiczny adres używany w internecie. Router zapisuje, które połączenie wewnętrzne odpowiada danemu przypisaniu adresu zewnętrznego i portu. Rozwiązanie zachowujące stały adres zewnętrzny lub korzystające z odpowiedniego tunelu ma inne warunki działania. Twierdzenie, że każde przełączenie kończy wszystkie sesje, byłoby więc nieprawdziwe.

Dlaczego zmiana adresu przerywa zwykłe TCP

Zwykłe połączenie TCP identyfikują adresy źródła i celu oraz porty. Jeśli po przełączeniu ruch jest tłumaczony na inny publiczny adres źródłowy, serwer nie może traktować tego ruchu jako poprzedniego połączenia. Sama nowa trasa nie przenosi stanu TCP na nowy adres.

Błąd nie musi stać się widoczny dokładnie w chwili przełączenia. Stan NAT może początkowo pozostać przypisany do WAN1; aplikacje mogą czekać na retransmisje lub wcześniej przerwać pracę przez własne limity czasu. Jeśli pierwotna droga wróci odpowiednio szybko z zachowanym stanem, połączenie może działać dalej. Zwykła zmiana adresu źródłowego wymaga natomiast zazwyczaj nowego połączenia SSH lub z bazą danych.

Wykrycie awarii, zmiana trasy i powrót aplikacji

Żaden wzór oparty wyłącznie na interwale i liczbie błędów nie opisuje wszystkich routerów. Prosty model można jednak wyprowadzić jednoznacznie: testy rozpoczynają się co I, każdy nieudany test kończy się po T, a dokładnie N kolejnych niepowodzeń uruchamia decyzję. Obowiązuje T < I, a ostatni test przed awarią zakończył się powodzeniem. d oznacza oczekiwanie na pierwszy start testu po awarii, a D to czas wykrycia.

I = 5 s, T = 1 s, N = 3
0 <= d < I
D = d + (N - 1) * I + T

11 s <= D < 16 s
średnia D = 13,5 s  (równomierny rozkład d)

Średnia zakłada, że awaria jest równie prawdopodobna w każdej chwili między rozpoczęciem dwóch kolejnych testów. Obliczenie nie obejmuje późniejszej zmiany tras ani powrotu aplikacji. Inna definicja tolerowanych błędów, ocena utraconych pakietów w stale przesuwanym przedziale czasu, opóźniona ocena lub rozpoczynanie testów dopiero po zakończeniu poprzednich zmieniają model. Przykładowo pfSense dokumentuje także progi strat, okresy oceny i interwały alarmów.

Co może działać dalej

QUIC potrafi przypisywać pakiety do połączenia za pomocą identyfikatorów połączenia. Nowa droga nadal musi działać i przejść weryfikację. Aktywna migracja wymaga potwierdzonego handshake i może być ograniczona; zmiana adresu wywołana przez NAT wymaga osobnego rozpatrzenia. Samo HTTP/3 nie gwarantuje nieprzerwanego działania aplikacji.

VPN musi zachować adresy wewnętrzne i istotne stany. Ruch internetowy przez zdalne wyjście VPN potrzebuje również stabilnego mapowania zewnętrznego w tym miejscu. WireGuard obsługuje roaming, a IKEv2 może korzystać z MOBIKE. Jeżeli przerwa przekroczy limit czasu aplikacji wewnętrznej, sam stały adres nie zachowa sesji.

Powrót bez zbędnej drugiej przerwy

Powrót do WAN1 nie musi natychmiast przenosić istniejących połączeń z WAN2. Router może preferować WAN1 dla nowych połączeń, pozostawiając dotychczasowe stany WAN2 do naturalnego wygaśnięcia. Wymuszone przekierowanie lub usunięcie stanów może natomiast wywołać kolejną przerwę. Rzeczywiste zachowanie zależy od konfiguracji.

Opóźniony powrót i odrębne kryteria awarii oraz przywrócenia ograniczają częste przełączanie. Stała proporcja timerów nie jest uniwersalnym rozwiązaniem. Decydują stabilność łącza, wymagania aplikacji i obsługa stanów.

Miarodajny test przełączania awaryjnego

Ruch kontrolny musi rzeczywiście przechodzić przez sprawdzane łącze. Odpowiedź modemu nie dowodzi dostępności internetu, a niedostępny pojedynczy cel testowy nie dowodzi awarii łącza. Kilka odpowiednich sygnałów lub celów może poprawić ocenę, jeżeli router to obsługuje. W pfSense każda brama wymaga odrębnego adresu IP monitorowania.

Planowany test osobno rejestruje moment awarii, decyzję dotyczącą bramy, udane nowe połączenie i powrót trwających operacji aplikacji. Test powinien obejmować także powrót na łącze główne, rozmowy przychodzące i rzeczywiście używane protokoły. Wznawialne pobieranie i kopie zapasowe zmniejszają skutki bez obietnicy zachowania każdej sesji.