A VPN a lap közepén szakadt meg: mennek-e még ki a háttérkérések?

A lap még a dashboardot mutatja abból az időből, mielőtt az alagút meghalt. Az állapotszámok megfagynak, egy kis pörgő tovább forog, és a címsor még mindig azt az alkalmazást hordozza, amelyet egy órája nyitott meg. Nem nyúlt semmihez a kiesés után, mégis lehet, hogy a lap továbbra is a saját ütemezése szerint próbálja elérni a szerverét. Ez az a rész, amit az emberek kihagynak: a csupán látható lap és a még mindig kéréseket küldő lap kívülről egyformán néz ki, és csak az egyikük jelenik meg egy hálózati naplóban.

Munka, amelyet a lap ön nélkül indít

Négy mechanizmus tart elfoglalva egy betöltött dokumentumot. Egy ismétlődő időzítő néhány másodpercenként újrafuttathat egy állapothívást. Egy fetch akkor indulhat, amikor a lap visszatérése után újra láthatóvá válik. Egy WebSocketre vagy szerver által küldött eseményekre épülő élő csatorna a saját visszalépési ütemezése szerint próbálhat újracsatlakozni. A webhely által regisztrált service worker akkor is felébredhet egy sorba állított szinkronizáláshoz, ha nincs lap ön előtt.

Egyik sem igényel kattintást, és egyik sem tölti újra a dokumentumot. A címsor, a görgetési pozíció és a megjelenített értékek mind ott maradnak, ahol voltak. Csak a hálózati oldal változik: minden új kísérlet friss döntés, amely abban a pillanatban születik, amikor elkezdődik.

Ez a megkülönböztetés azért fontos, mert a látható lap helyben tárolódik. A már kirajzolt pixelek semmit sem mondanak arról, hogy sikerült-e a következő kérés. A pörgővel megfagyott diagram a szokásos képe egy olyan lapnak, amelynek kérései most meghiúsulnak. A képernyő olvasása azt mondja meg, mit mondott a szerver percekkel ezelőtt, nem azt, hogy a böngésző most mit tesz.

Miért nem tart útvonalat a korábbi lapbetöltés

Semmi a lapbetöltésben nem köti a dokumentumot az alagúthoz. Az útválasztás csomagonként, küldéskor oldódik meg abból a táblából, amely a csomag távozásakor létezik. Amikor az alagút interfész eltűnik, ez a keresés már nem egyezik az alagút útvonalával. Vagy átesik a fizikai adapterre, vagy semmit sem talál, attól függően, mit hagyott maga után a kliens.

Az ismétlődő visszahívások közönséges ütemezett feladatok. A HTML szabvány időzítőkről szóló szakasza leírja, hogyan kerülnek sorba, és az intervallumot minimális késleltetésként kezeli, nem pedig a pontos ütem ígéretként, így egy háttérlap sokkal ritkábban kérdezhet, mint amennyit a kódja kér. A kevesebb kísérlet nem ugyanaz, mint a semmilyen kísérlet, és a lap előtérbe hozása gyakori pillanata az ilyenek rohamának.

Hová kerül a hiba politika

Az ügyfél blokkolása akkor értékelődik, amikor kapcsolatot kísérelnek meg, nem akkor, amikor a lapot letöltötték. Ha a szokásos hozzáférés továbbra is engedélyezett, az újrapróbálkozás a fizikai kapcsolaton keresztül nyíltan kimehet. Ha a szabályzat visszatartja ezt a forgalmat, amíg az alagút vissza nem tér, a kísérlet a kapcsolódás pillanatában meghiúsul, és a lap olyan hibát mutat, amelyet néhány másodperc múlva újra próbálhat.

Két részlet dönti el, melyiket kapja. Az első az érvényesítési hatókör, amelyet a kliens támogat: blokk az egész eszközre, az alagút adapterére korlátozott blokk, vagy kivételekkel rendelkező szabálykészlet. A második az, hogy a cél beleesik-e egy korábban hozzáadott kivételbe egy helyi nyomtató, egy captive portal vagy egy streaming szolgáltatás esetében.

Az alkalmazásszintű titkosítás ezen semmit sem változtat. A HTTPS védi a bájtokat a böngésző és a szerver között; semmit sem mond arról, melyik interfész szállítja őket. Egy lap lehet tökéletesen titkosított, és mégis a rossz úton mehet ki, és pontosan ezt engedi meg egy szűk blokk.

Ellenőrzött vizsgálat egy eldobható lappal

Használjon egy Ön által vezérelt gazdagépet és egy lapot, amely nem tesz mást, mint meghívja, hogy ne legyen valódi adat játékban. Terminálból vegyen mintát az útvonalról a kiesés előtt és után:

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

Futtassa felhúzott alagúttal, majd engedje le az alagutat, és futtassa újra. Nyilvános címről érkező válasz leengedett alagút mellett azt mondja, hogy a közvetlen útvonal nyitva van. Egy időtúllépés vagy egy elutasított kapcsolat azt mondja, hogy a szabályzat tart. Ismételje meg még egyszer, miután a kliens újracsatlakozott, hogy lássa az alagút útvonalát visszatérni, ahelyett hogy feltételezné.

A böngészőben a Hálózat panel szétválasztja a két kérdést. Szűrjön a Fetch/XHR-re, majd olvassa el a kezdeményező oszlopot: egy időzítő vagy szkript által indított bejegyzés, amely előtt nincs rögzített navigáció, háttérkísérlet, nem újratöltés. Hasonlítsa össze a kezdési idejét azzal a pillanattal, amikor az alagút megszakadt. Ha a bejegyzés még függőben van, amikor az alagút már nincs ott, a kérés egy már nem létező útvonalra vár.

A szerveroldali bizonyíték erősebb mindennél, amit a böngésző mutat. Egy időbélyeggel és forrás címmel ellátott kérésnapló bizonyítja, hogy a csomag megérkezett. A böngésző bejegyzései sütiket, tokeneket és teljes URL-eket hordozhatnak, ezért csak a kérdéséhez szükséges mezőket tartsa meg, a többit pedig takarja ki, mielőtt bárhová beilleszti.

Mit tegyen a válasszal

Ha a háttérkísérletek továbbra is sikeresek, miközben az alagút le van engedve, a blokk szűkebb, mint feltételezte, és azt a rést érdemes bezárni, mielőtt érzékeny munkát bíz a kliensre. Ha meghiúsulnak, a szabályzat végzi a dolgát, és a megfagyott lap kozmetikai. Akárhogy is, egy lap bezárása nem eszközszintű ellenőrzés: más lapok, más böngészők és más alkalmazások mindegyike a saját munkáját ütemezi.

Érdemes következő lépések: sorolja fel, milyen kivételeket adott hozzá és miért, erősítse meg, hogy a kliens csak az alagút hatókörébe tartozó forgalmat vagy minden forgalmat blokkol, és figyeljen meg egy háttérkérést elejétől a végéig nyitott szervernaplóval. Ez a három válasz lefedi a legtöbbet abból, amit egy „a VPN megszakadt, és valami még mindig csatlakozik” típusú jelentés valójában tartalmaz.