VPN połączył się ponownie, ale sesja aplikacji nadal zawodzi

Tunel wraca, klient zgłasza połączenie, a przeglądarka wciąż kręci się na stronie, którą ładowała przed zerwaniem. Ponowne połączenie VPN przywraca ścieżkę i nie przywraca stanu połączenia, który aplikacje i druga strona zgromadziły na starej. To dwie różne rzeczy do naprawy, a ich mylenie odsyła cię do ustawień VPN bez powodu.

Jeden test czysto je rozdziela, i zajmuje dziesięć sekund. Wyślij nowe żądanie do tego samego celu, gdy stare wisi.

Co przetrwa ponowne połączenie, a co nie

Tunel to zbiór tras, kluczy i adresów, a ponowne połączenie może przywrócić wszystkie trzy, podczas gdy każdy ustanowiony przepływ pozostaje martwy. System operacyjny trzyma gniazdo otwarte, bo aplikacja o to poprosiła, a limit czasu tego gniazda może być o minuty lub godziny dalej. Pod spodem partner zapomniał przepływu, wpis tłumaczenia wygasł albo ścieżka biegnie teraz przez punkt końcowy, który nigdy nie widział uścisku dłoni. Nic w sekwencji ponownego połączenia nie przechodzi przez gniazda aplikacji i ich nie naprawia.

Niektóre klienty dodają hak, który przy ponownym połączeniu wyrzuca nieaktualne połączenia, a większość nie. Zachowanie tutaj zależy od klienta, platformy i wersji.

Druga strona też o tobie zapomniała

Daleki koniec trzyma własny stan: sesję TLS, blok kontrolny TCP i być może wpis mapowania, który wiąże twój adres i port z przepływem. Urządzenie tłumaczące na ścieżce może pozwolić temu mapowaniu wygasnąć w czasie przerwy, nawet gdy tunel szybko się odtwarza. Gdy mapowanie znika, przychodzą pakiety dla przepływu, którego serwer już nie rozpoznaje, a odpowiedzią może być reset, którego klient nigdy nie pokazuje. Aplikacje zgłaszają to jako zawieszenie, a nie błąd, bo wciąż czekają na gniazdo, które nigdy nie odpowie.

Limity bezczynności po stronie serwera robią to samo według własnego harmonogramu, dlatego sesja może umrzeć bez żadnego zdarzenia sieciowego. Połączenie, które było bezczynne dłużej, niż serwer oczekuje, już zniknęło, zanim zauważysz, że tunel się przesunął.

Nowe żądanie to test, który je rozdziela

Wyślij nowe żądanie do tego samego hosta, gdy stare nadal wisi, i obserwuj oba. Jeśli nowe żądanie się powiedzie, tunel, trasa i rozwiązywanie nazw działają, a usterka ogranicza się do nieaktualnego przepływu. Jeśli nowe żądanie też zawiedzie, masz problem ze ścieżką, a stan sesji aplikacji to fałszywy trop.

Podczas testu zostaw w miejscu każdą blokadę ruchu bezpośredniego. Żądanie, które udaje się przez przypadkową ścieżkę zapasową, niczego nie dowodzi o tunelu.

Potwierdź nowym połączeniem, nie starym

Poniższe polecenia pokazują wciąż otwarte gniazda, uruchamiają jedno nowe żądanie i sprawdzają, czy tabela sesji nadal ma wpis dla przepływu. Uruchom pierwsze przed ponownym połączeniem i po nim, żeby różnica była widoczna. Zastąp hosta i port własną usługą.

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

Ustanowione gniazdo bez ruchu to sygnatura, której szukasz, a nowe żądanie zwracające kod stanu pokazuje, że ścieżka żyje. Tabela połączeń odpowiada, czy coś jeszcze mapuje przepływ, i to jest część, której klient nie widzi. Zapytanie do resolvera pokrywa drugą połowę ładowania strony, ponieważ błąd nazwy i zawieszone połączenie wyglądają w przeglądarce tak samo. Razem te cztery wyniki oddzielają nieaktualną sesję od zepsutego tunelu.

Zapisz czas przerwania, czas ponownego połączenia i różnicę między starym a nowym żądaniem. Ten zapis zamienia mgliste skargi w raport, na którym ktoś może działać.