VPN katkes keset lehte: kas taustapäringud lähevad ikka välja?

Vahekaart näitab endiselt armatuurlaua vaadet ajast enne, kui tunnel suri. Olekunumbrid külmuvad, väike spiraal jätkab pöörlemist ja aadressiribal on endiselt rakendus, mille avasite tund aega tagasi. Te ei puudutanud pärast katkestust midagi, kuid leht võib siiski proovida oma serverini jõuda oma ajakava järgi. Just seda inimesed mööda vaatavad: leht, mis on ainult nähtav, ja leht, mis saadab endiselt päringuid, näevad väljastpoolt ühesugused välja ning ainult üks neist ilmub võrgulogi.

Töö, mille leht alustab ilma sinuta

Neli mehhanismi hoiavad laaditud dokumenti ametis. Korduv taimer võib iga mõne sekundi järel olekukutse uuesti käivitada. Fetch võib vallanduda siis, kui vahekaart muutub pärast sinna naasmist uuesti nähtavaks. WebSocketil või serveri saadetud sündmustel põhinev reaalajas kanal võib proovida uuesti ühenduda oma tagasilöögi ajakava järgi. Saidi registreeritud teenustöötaja võib ärgata järjekorda pandud sünkroonimise jaoks ka siis, kui teie ees pole ühtegi vahekaarti.

Ükski neist ei vaja klõpsu ja ükski ei laadi dokumenti uuesti. Aadressiriba, kerimisasukoht ja kuvatud väärtused jäävad kõik sinna, kus need olid. Muutub ainult võrgupool: iga uus katse on värske otsus, mis tehakse hetkel, mil see algab.

See erinevus on oluline, sest nähtav leht on salvestatud kohapeal. Juba joonistatud pikslid ei ütle midagi selle kohta, kas järgmine päring õnnestus. Külmunud diagramm spiraaliga on tavaline välimus lehel, mille päringud nüüd ebaõnnestuvad. Ekraani lugemine ütleb teile, mida server ütles mitu minutit tagasi, mitte seda, mida brauser praegu teeb.

Miks varasem lehe laadimine marsruuti ei hoia

Miski lehe laadimises ei seo dokumenti tunneliga. Marsruutimine lahendatakse paketi kaupa saatmise hetkel tabelist, mis on olemas siis, kui pakett lahkub. Kui tunneliliides kaob, ei vasta see otsing enam tunnelimarsruudile. See kas langeb füüsilisele adapterile või ei leia üldse midagi, sõltuvalt sellest, mille klient maha jättis.

Korduvad tagasikutsumised on tavalised ajastatud ülesanded. HTML-standardi taimerijaotis kirjeldab, kuidas neid järjekorda pannakse, ja käsitleb intervalli minimaalse viivitusena, mitte täpse rütmi lubadusena, nii et taustavahekaart võib küsida palju harvemini, kui selle kood nõuab. Vähem katseid ei ole sama mis üldse mitte katseid, ja vahekaardi tagasi esiplaanile toomine on nende purse jaoks tavaline hetk.

Kuhu tõrkepoliitika maandub

Kliendi blokeeringut hinnatakse siis, kui ühendust proovitakse, mitte siis, kui leht toodi. Kui tavaline juurdepääs on endiselt lubatud, võib korduskatse minna füüsilise lingi kaudu avalikult välja. Kui poliitika hoiab seda liiklust kuni tunneli naasmiseni, ebaõnnestub katse ühendamise hetkel ja leht näitab viga, mida see võib mõne sekundi pärast uuesti proovida.

Kaks detaili otsustavad, millise neist saate. Esimene on jõustamisulatus, mida klient toetab: kogu seadme blokeering, tunneladapteriga piiratud blokeering või eranditega reeglistik. Teine on see, kas sihtkoht jääb varasemalt lisatud erandi sisse kohaliku printeri, captive portaali või voogedastusteenuse jaoks.

Rakendustasandi krüpteerimine ei muuda sellest midagi. HTTPS kaitseb baite brauseri ja serveri vahel; see ei ütle midagi selle kohta, milline liides neid kannab. Leht võib olla täiuslikult krüpteeritud ja siiski valest teest välja minna, ja täpselt seda kitsas blokeering lubabki.

Kontrollitud test ühekordse lehega

Kasutage hosti, mida kontrollite, ja lehte, mis ei tee muud kui seda kutsub, et mängus poleks päris andmeid. Terminalist võtke tee proov enne katkestust ja pärast:

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

Käivitage see tunneliga üleval, seejärel lülitage tunnel alla ja käivitage uuesti. Vastus avalikult aadressilt, kui tunnel on maas, ütleb teile, et otsetee on avatud. Ajalõpp või keeldutud ühendus ütleb teile, et poliitika hoiab. Korrake veel kord pärast seda, kui klient on uuesti ühendunud, et näha tunnelitee naasmist, selle asemel et seda eeldada.

Brauseris eraldab võrgupaneel kaks küsimust. Filtreerige Fetch/XHR-ile, seejärel lugege algataja veergu: taimeri või skripti käivitatud kirje, mille ees pole navigeerimist registreeritud, on taustakatse, mitte uuestilaadimine. Võrrelge selle algusaega hetkega, mil tunnel katkes. Kui kirje on endiselt ootel, kui tunnel on kadunud, ootab päring teed, mida enam ei ole.

Serveripoolsed tõendid on tugevamad kui kõik, mida brauser näitab. Päringulogi ajatempli ja lähteaadressiga tõestab, et pakett saabus. Brauseri kirjed võivad kanda küpsiseid, tunnuseid ja täielikke URL-e, seega jätke alles ainult väljad, mida teie küsimus vajab, ja katke ülejäänu, enne kui need kuhugi kleepite.

Mida vastusega teha

Kui taustakatsed jätkavad õnnestumist, kui tunnel on maas, on blokeering kitsam, kui eeldasite, ja see lünk tasub sulgeda enne, kui usaldate kliendi tundlikku tööd. Kui need ebaõnnestuvad, teeb poliitika oma tööd ja külmunud leht on kosmeetiline. Mõlemal juhul ei ole ühe vahekaardi sulgemine kogu seadme kontroll: teised vahekaardid, teised brauserid ja teised rakendused planeerivad igaüks oma tööd.

Järgmised sammud, mida tasub astuda: loetlege, millised erandid olete lisanud ja miks, kinnitage, kas klient blokeerib ainult tunneliulatusega liiklust või kogu liiklust, ja jälgige üht taustapäringut algusest lõpuni avatud serverilogiga. Need kolm vastust katavad suurema osa sellest, mida aruanne «VPN katkes ja miski on endiselt ühendatud» tegelikult sisaldab.