VPN padł w środku strony: czy żądania w tle nadal wychodzą?

Karta nadal pokazuje pulpit sprzed śmierci tunelu. Liczby stanu zamierają, mały wskaźnik nadal się kręci, a pasek adresu wciąż niesie aplikację, którą otworzyłeś godzinę temu. Po zerwaniu niczego nie dotknąłeś, a jednak strona może nadal próbować dotrzeć do swojego serwera według własnego harmonogramu. To właśnie ludzie przeoczają: strona, która tylko jest widoczna, i strona, która nadal wysyła żądania, wyglądają z zewnątrz identycznie, a tylko jedna z nich pojawia się w dzienniku sieci.

Praca, którą strona zaczyna bez ciebie

Cztery mechanizmy trzymają załadowany dokument zajęty. Powtarzający się timer może co kilka sekund ponownie uruchamiać wywołanie stanu. Fetch może zadziałać, gdy karta znów stanie się widoczna po powrocie do niej. Kanał na żywo zbudowany na WebSocket lub zdarzeniach wysyłanych przez serwer może próbować ponownego połączenia według własnego harmonogramu wycofywania. Service worker zarejestrowany przez witrynę może się obudzić do synchronizacji w kolejce, nawet gdy przed tobą nie ma żadnej karty.

Żaden z nich nie wymaga kliknięcia i żaden nie przeładowuje dokumentu. Pasek adresu, pozycja przewijania i wyświetlane wartości pozostają tam, gdzie były. Zmienia się tylko strona sieciowa: każda nowa próba to świeża decyzja podjęta w momencie, w którym się zaczyna.

To rozróżnienie ma znaczenie, bo widoczna strona jest przechowywana lokalnie. Już namalowane piksele nie mówią nic o tym, czy następne żądanie się powiodło. Zamarły wykres ze wskaźnikiem to zwykły wygląd strony, której żądania teraz zawodzą. Czytanie ekranu mówi ci, co serwer powiedział kilka minut temu, a nie co robi teraz przeglądarka.

Dlaczego wcześniejsze ładowanie strony nie utrzymuje trasy

Nic w ładowaniu strony nie wiąże dokumentu z tunelem. Trasowanie jest rozwiązywane dla każdego pakietu, w momencie wysyłania, z tabeli, która istnieje, gdy pakiet wychodzi. Gdy interfejs tunelu znika, to wyszukiwanie nie pasuje już do trasy tunelu. Albo spada na kartę fizyczną, albo niczego nie znajduje, w zależności od tego, co zostawił klient.

Powtarzane wywołania zwrotne to zwykłe zadania zaplanowane. Sekcja timerów standardu HTML opisuje, jak są kolejkowane, i traktuje interwał jako minimalne opóźnienie, a nie obietnicę dokładnego rytmu, więc karta w tle może odpytować znacznie rzadziej, niż prosi o to jej kod. Mniej prób to nie to samo co brak prób, a przywrócenie karty na wierzch to częsty moment na ich wybuch.

Gdzie ląduje polityka błędów

Blokada klienta jest oceniana, gdy próbuje się połączenia, a nie gdy strona została pobrana. Jeśli zwykły dostęp jest nadal dozwolony, ponowna próba może wyjść przez łącze fizyczne jawnie. Jeśli polityka wstrzymuje ten ruch do powrotu tunelu, próba nie udaje się w momencie połączenia, a strona pokazuje błąd, który może powtórzyć kilka sekund później.

Dwa szczegóły decydują, który z nich dostaniesz. Pierwszy to zakres egzekwowania obsługiwany przez klienta: blokada całego urządzenia, blokada ograniczona do adaptera tunelu albo zestaw reguł z wyjątkami. Drugi to, czy cel mieści się w wyjątku dodanym wcześniej dla lokalnej drukarki, portalu przechwytującego lub usługi streamingowej.

Szyfrowanie na poziomie aplikacji niczego z tego nie zmienia. HTTPS chroni bajty między przeglądarką a serwerem; nie mówi nic o tym, który interfejs je przenosi. Strona może być doskonale zaszyfrowana i nadal wychodzić złą drogą, i dokładnie to umożliwia wąska blokada.

Kontrolowana kontrola z jednorazową stroną

Użyj hosta, który kontrolujesz, i strony, która nie robi niczego poza wywoływaniem go, aby w grze nie było prawdziwych danych. Z terminala pobierz próbkę ścieżki przed zerwaniem i po nim:

curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/ping

Uruchom to z podniesionym tunelem, potem opuść tunel i uruchom ponownie. Odpowiedź z publicznego adresu przy opuszczonym tunelu mówi ci, że bezpośrednia ścieżka jest otwarta. Przekroczenie limitu czasu lub odrzucone połączenie mówi ci, że polityka trzyma. Powtórz jeszcze raz, gdy klient ponownie się połączy, aby zobaczyć powrót ścieżki tunelu zamiast zakładać, że tak się stało.

W przeglądarce panel Sieć rozdziela oba pytania. Filtruj do Fetch/XHR, potem czytaj kolumnę inicjatora: wpis uruchomiony przez timer lub skrypt, bez zarejestrowanej przed nim nawigacji, to próba w tle, a nie przeładowanie. Porównaj jego czas rozpoczęcia z momentem, w którym tunel padł. Jeśli wpis jest nadal w toku, gdy tunelu już nie ma, żądanie czeka na ścieżkę, która już nie istnieje.

Dowody po stronie serwera są silniejsze niż cokolwiek, co pokazuje przeglądarka. Dziennik żądań ze znacznikiem czasu i adresem źródłowym dowodzi, że pakiet dotarł. Wpisy przeglądarki mogą nieść pliki cookie, tokeny i pełne adresy URL, więc zachowaj tylko pola potrzebne do twojego pytania, a resztę zredaguj, zanim gdziekolwiek ją wkleisz.

Co zrobić z odpowiedzią

Jeśli próby w tle nadal się udają, gdy tunel jest opuszczony, blokada jest węższa, niż zakładałeś, i tę lukę warto zamknąć, zanim powierzysz klientowi wrażliwą pracę. Jeśli zawodzą, polityka robi swoje, a zamarznięta strona jest tylko kosmetyczna. Tak czy inaczej, zamknięcie jednej karty nie jest kontrolą całego urządzenia: inne karty, inne przeglądarki i inne aplikacje każde planują własną pracę.

Kolejne kroki, które warto podjąć: wypisz, jakie wyjątki dodałeś i dlaczego, potwierdź, czy klient blokuje tylko ruch w zakresie tunelu, czy cały ruch, i obserwuj jedno żądanie w tle od początku do końca z otwartym dziennikiem serwera. Te trzy odpowiedzi pokrywają większość tego, co naprawdę zawiera raport „VPN padł, a coś nadal jest połączone”.