VPN spadla uprostřed stránky: odcházejí na pozadí ještě požadavky?

Panel stále ukazuje nástěnku z doby předtím, než tunel zemřel. Čísla stavu zamrznou, malý indikátor se dál točí a adresní řádek stále nese aplikaci, kterou jste otevřeli před hodinou. Po výpadku jste se ničeho nedotkli, a přesto se stránka možná stále snaží dosáhnout svého serveru podle vlastního rozvrhu. To je ta část, kterou lidé přehlížejí: stránka, která je jen viditelná, a stránka, která stále posílá požadavky, vypadají zvenčí stejně a jen jedna z nich se objeví v síťovém záznamu.

Práce, kterou stránka začne bez vás

Čtyři mechanismy drží načtený dokument zaneprázdněný. Opakující se časovač může znovu spouštět volání stavu každých několik sekund. Fetch se může spustit, když se panel po vašem návratu znovu stane viditelným. Živý kanál postavený na WebSocketu nebo událostech ze serveru může zkusit opětovné připojení podle vlastního rozvrhu odstupu. Service worker zaregistrovaný stránkou se může probudit kvůli synchronizaci ve frontě, i když před vámi není žádný panel.

Nic z toho nepotřebuje kliknutí a nic z toho znovu nenačítá dokument. Adresní řádek, pozice posunu i vykreslené hodnoty zůstávají tam, kde byly. Mění se jen síťová strana: každý nový pokus je čerstvé rozhodnutí učiněné v okamžiku, kdy začíná.

Ten rozdíl je důležitý, protože viditelná stránka je uložena lokálně. Již vykreslené pixely nic neříkají o tom, zda další požadavek uspěl. Zamrzlý graf s indikátorem je běžný vzhled stránky, jejíž požadavky teď selhávají. Čtení obrazovky vám říká, co server řekl před několika minutami, ne co prohlížeč dělá teď.

Proč dřívější načtení stránky nedrží trasu

Nic v načtení stránky nepoutá dokument k tunelu. Směrování se řeší pro každý paket v okamžiku odeslání z tabulky, která existuje, když paket odchází. Když rozhraní tunelu zmizí, toto hledání už neodpovídá trase tunelu. Buď propadne na fyzický adaptér, nebo nenajde nic, podle toho, co klient zanechal.

Opakované zpětné volání je běžná naplánovaná úloha. Sekce standardu HTML o časovačích popisuje, jak se zařazují do fronty, a interval považuje za minimální zpoždění, nikoli za slib přesného rytmu, takže panel na pozadí může dotazovat mnohem méně často, než jeho kód žádá. Méně pokusů není totéž jako žádné pokusy a návrat panelu do popředí je běžný okamžik pro jejich nápor.

Kam dopadá politika selhání

Blok klienta se vyhodnocuje, když se pokusí o spojení, ne když byla stránka načtena. Pokud je běžný přístup stále povolen, může opakovaný pokus odejít přes fyzické spojení nešifrovaně. Pokud politika tento provoz zadržuje, dokud se tunel nevrátí, pokus selže v okamžiku připojení a stránka zobrazí chybu, kterou může za několik sekund zkusit znovu.

O tom, který z těchto případů dostanete, rozhodují dva detaily. Prvním je rozsah vynucení, který klient podporuje: blok pro celé zařízení, blok omezený na adaptér tunelu nebo sada pravidel s výjimkami. Druhým je, zda cíl spadá do výjimky, kterou jste dříve přidali pro místní tiskárnu, captive portál nebo streamovací službu.

Šifrování na úrovni aplikace na tom nic nemění. HTTPS chrání bajty mezi prohlížečem a serverem; neříká nic o tom, které rozhraní je přenáší. Stránka může být dokonale zašifrovaná a přesto odejít špatnou cestou, a přesně to úzký blok umožňuje.

Řízená kontrola s jednorázovou stránkou

Použijte hostitele, kterého ovládáte, a stránku, která nedělá nic jiného než že ho volá, aby ve hře nebyla žádná skutečná data. Z terminálu odeberte vzorek cesty před výpadkem a po něm:

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

Spusťte to se zapnutým tunelem, potom tunel vypněte a spusťte znovu. Odpověď z veřejné adresy při vypnutém tunelu vám říká, že přímá cesta je otevřená. Vypršení času nebo odmítnuté spojení vám říká, že politika drží. Zopakujte to ještě jednou poté, co se klient znovu připojí, abyste viděli, že se trasa tunelu vrací, místo abyste to předpokládali.

V prohlížeči panel Síť odděluje obě otázky. Filtrujte na Fetch/XHR a potom čtěte sloupec iniciátoru: záznam spuštěný časovačem nebo skriptem, bez zaznamenané navigace před ním, je pokus na pozadí, nikoli znovunačtení. Porovnejte jeho čas spuštění s okamžikem, kdy tunel spadl. Pokud je záznam stále nevyřízený, když tunel zmizel, požadavek čeká na cestu, která už neexistuje.

Důkazy na straně serveru jsou silnější než cokoli, co prohlížeč ukáže. Protokol požadavků s časovým razítkem a zdrojovou adresou dokazuje, že paket dorazil. Záznamy v prohlížeči mohou nést cookies, tokeny a plné URL, proto si ponechte jen pole, která vaše otázka potřebuje, a zbytek začerněte, než je někam vložíte.

Co s odpovědí dělat

Pokud pokusy na pozadí dál uspějí, když je tunel vypnutý, blok je užší, než jste předpokládali, a tu mezeru stojí za to zavřít, než klientovi svěříte citlivou práci. Pokud selhávají, politika dělá svou práci a zamrzlá stránka je kosmetická. Ať tak či onak, zavření jednoho panelu není ovládání pro celé zařízení: jiné panely, jiné prohlížeče a jiné aplikace si každý plánují vlastní práci.

Následující kroky, které stojí za to: vypište, které výjimky jste přidali a proč, potvrďte, zda klient blokuje jen provoz v rozsahu tunelu, nebo veškerý provoz, a sledujte jeden požadavek na pozadí od začátku do konce s otevřeným protokolem serveru. Ty tři odpovědi pokrývají většinu toho, co zpráva „VPN spadla a něco je pořád připojené“ vlastně obsahuje.