VPN padlo v strede stránky: odchádzajú na pozadí ešte požiadavky?

Karta stále zobrazuje nástenku z čias predtým, než tunel zomrel. Čísla stavu zamrznú, malý indikátor sa ďalej otáča a adresný riadok stále nesie aplikáciu, ktorú ste otvorili pred hodinou. Po výpadku ste sa ničoho nedotkli, a napriek tomu sa stránka možno stále snaží dosiahnuť svoj server podľa vlastného rozvrhu. To je tá časť, ktorú ľudia prehliadajú: stránka, ktorá je len viditeľná, a stránka, ktorá stále posiela požiadavky, vyzerajú zvonku rovnako a iba jedna z nich sa objaví v sieťovom zázname.

Práca, ktorú stránka začne bez vás

Štyri mechanizmy držia načítaný dokument zaneprázdnený. Opakujúci sa časovač môže znova spúšťať volanie stavu každých niekoľko sekúnd. Fetch sa môže spustiť, keď sa karta po vašom návrate znova stane viditeľnou. Živý kanál postavený na WebSockete alebo udalostiach zo servera môže skúsiť opätovné pripojenie podľa vlastného rozvrhu odstupu. Service worker zaregistrovaný stránkou sa môže zobudiť kvôli synchronizácii vo fronte, aj keď pred vami nie je žiadna karta.

Nič z toho nepotrebuje kliknutie a nič z toho znova nenačítava dokument. Adresný riadok, pozícia posunu aj vykreslené hodnoty zostávajú tam, kde boli. Mení sa len sieťová strana: každý nový pokus je čerstvé rozhodnutie urobené v okamihu, keď sa začína.

Ten rozdiel je dôležitý, pretože viditeľná stránka je uložená lokálne. Už vykreslené pixely nehovoria nič o tom, či ďalšia požiadavka uspela. Zamrznutý graf s indikátorom je bežný vzhľad stránky, ktorej požiadavky teraz zlyhávajú. Čítanie obrazovky vám povie, čo server povedal pred niekoľkými minútami, nie čo prehliadač robí teraz.

Prečo skoršie načítanie stránky nedrží trasu

Nič v načítaní stránky nepútá dokument k tunelu. Smerovanie sa rieši pre každý paket v okamihu odoslania z tabuľky, ktorá existuje, keď paket odchádza. Keď rozhranie tunela zmizne, toto hľadanie už neodpovedá trase tunela. Buď prepadne na fyzický adaptér, alebo nič nenájde, podľa toho, čo klient zanechal.

Opakované spätné volania sú bežné naplánované úlohy. Sekcia časovačov štandardu HTML opisuje, ako sa zaraďujú do fronty, a interval považuje za minimálne oneskorenie, nie za prísľub presného rytmu, takže karta na pozadí môže dopytovať oveľa menej často, než žiada jej kód. Menej pokusov nie je to isté ako žiadne pokusy a návrat karty do popredia je bežný okamih pre ich nával.

Kam dopadá politika zlyhania

Blok klienta sa vyhodnocuje, keď sa pokúsi o spojenie, nie keď sa stránka načítala. Ak je bežný prístup stále povolený, opakovaný pokus môže odísť cez fyzické spojenie nešifrovane. Ak politika tento prenos zadržiava, kým sa tunel nevráti, pokus zlyhá v okamihu pripojenia a stránka zobrazí chybu, ktorú môže o niekoľko sekúnd skúsiť znova.

O tom, ktorý z týchto prípadov dostanete, rozhodujú dva detaily. Prvým je rozsah presadzovania, ktorý klient podporuje: blok pre celé zariadenie, blok obmedzený na adaptér tunela alebo sada pravidiel s výnimkami. Druhým je, či cieľ spadá do výnimky, ktorú ste predtým pridali pre miestnu tlačiareň, captive portál alebo streamovaciu službu.

Šifrovanie na úrovni aplikácie na tom nič nemení. HTTPS chráni bajty medzi prehliadačom a serverom; nehovorí nič o tom, ktoré rozhranie ich prenáša. Stránka môže byť dokonale zašifrovaná a predsa odísť nesprávnou cestou, a presne to úzky blok umožňuje.

Riadená kontrola s jednorazovou stránkou

Použite hostiteľa, ktorého ovládate, a stránku, ktorá nerobí nič iné, len ho volá, aby v hre neboli žiadne skutočné údaje. Z terminálu odoberte vzorku cesty pred výpadkom a po ňom:

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

Spustite to so zapnutým tunelom, potom tunel vypnite a spustite znova. Odpoveď z verejnej adresy pri vypnutom tuneli vám hovorí, že priama cesta je otvorená. Vypršanie času alebo odmietnuté spojenie vám hovorí, že politika drží. Zopakujte to ešte raz po tom, čo sa klient znova pripojí, aby ste videli návrat trasy tunela, namiesto toho, aby ste to predpokladali.

V prehliadači panel Sieť oddeľuje obe otázky. Filtrujte na Fetch/XHR a potom čítajte stĺpec iniciátora: záznam spustený časovačom alebo skriptom, bez zaznamenanej navigácie pred ním, je pokus na pozadí, nie opätovné načítanie. Porovnajte jeho čas spustenia s okamihom, keď tunel padol. Ak je záznam ešte nevybavený, keď tunel zmizol, požiadavka čaká na cestu, ktorá už neexistuje.

Dôkazy na strane servera sú silnejšie než čokoľvek, čo prehliadač ukáže. Protokol požiadaviek s časovou značkou a zdrojovou adresou dokazuje, že paket dorazil. Záznamy v prehliadači môžu niesť cookies, tokeny a plné URL, preto si ponechajte len polia, ktoré vaša otázka potrebuje, a zvyšok začiernite, než ich niekam vložíte.

Čo s odpoveďou robiť

Ak pokusy na pozadí ďalej uspejú, keď je tunel vypnutý, blok je užší, než ste predpokladali, a tú medzeru sa oplatí zavrieť, než klientovi zveríte citlivú prácu. Ak zlyhávajú, politika robí svoju prácu a zamrznutá stránka je kosmetická. Tak či onak, zavretie jednej karty nie je ovládanie celého zariadenia: iné karty, iné prehliadače a iné aplikácie si každé plánujú vlastnú prácu.

Nasledujúce kroky, ktoré stoja za to: vypíšte, ktoré výnimky ste pridali a prečo, potvrďte, či klient blokuje len prevádzku v rozsahu tunela alebo všetku prevádzku, a sledujte jednu požiadavku na pozadí od začiatku do konca s otvoreným protokolom servera. Tie tri odpovede pokrývajú väčšinu toho, čo správa „VPN padlo a niečo je stále pripojené“ v skutočnosti obsahuje.