VPN katkesi kesken sivua: lähtevätkö taustapyynnöt yhä ulos?

Välilehti näyttää yhä hallintapaneelin ajalta ennen tunnelin kuolemaa. Tilanumerot jäätyvät, pieni pyörijä jatkaa pyörimistä ja osoitepalkissa on yhä sovellus, jonka avasit tunti sitten. Et koskenut mihinkään katkoksen jälkeen, ja silti sivu saattaa yhä yrittää tavoittaa palvelimensa oman aikataulunsa mukaan. Juuri sen ihmiset ohittavat: sivu, joka on vain näkyvissä, ja sivu, joka yhä lähettää pyyntöjä, näyttävät ulkoapäin samoilta, ja vain toinen niistä näkyy verkkolokissa.

Työ, jonka sivu aloittaa ilman sinua

Neljä mekanismia pitää ladatun asiakirjan kiireisenä. Toistuva ajastin voi suorittaa tilakutsun uudelleen muutaman sekunnin välein. Fetch voi laueta, kun välilehti tulee uudelleen näkyväksi sen jälkeen, kun palaat siihen. WebSocketille tai palvelimen lähettämille tapahtumille rakennettu live-kanava voi yrittää uudelleenyhdistämistä oman perääntymisaikataulunsa mukaan. Sivuston rekisteröimä service worker voi herätä jonossa olevalle synkronoinnille, vaikka edessäsi ei olisi yhtään välilehteä.

Mikään niistä ei vaadi napsautusta, eikä mikään lataa asiakirjaa uudelleen. Osoitepalkki, vierityskohta ja renderöidyt arvot pysyvät kaikki paikoillaan. Muuttuu vain verkkopuoli: jokainen uusi yritys on tuore päätös, joka tehdään hetkellä, jolloin se alkaa.

Tällä erolla on merkitystä, koska näkyvä sivu on tallennettu paikallisesti. Jo piirretyt pikselit eivät kerro mitään siitä, onnistuiko seuraava pyyntö. Jäätynyt kaavio pyörijän kanssa on tavallinen ulkoasu sivulle, jonka pyynnöt nyt epäonnistuvat. Näytön lukeminen kertoo, mitä palvelin sanoi minuutteja sitten, ei sitä, mitä selain tekee nyt.

Miksi aiempi sivun lataus ei pidä reittiä

Mikään sivun latauksessa ei sido asiakirjaa tunneliin. Reititys ratkaistaan pakettikohtaisesti lähetyshetkellä taulusta, joka on olemassa, kun paketti lähtee. Kun tunnelin liitäntä katoaa, se haku ei enää vastaa tunnelin reittiä. Se joko putoaa fyysiselle sovittimelle tai ei löydä mitään, riippuen siitä, mitä asiakas jätti jälkeensä.

Toistuvat takaisinkutsut ovat tavallisia ajastettuja tehtäviä. HTML-standardin ajastinosio kuvaa, miten ne asetetaan jonoon, ja kohtelee väliä vähimmäisviiveenä eikä lupauksena tarkasta tahdista, joten taustavälilehti voi kysellä paljon harvemmin kuin sen koodi pyytää. Harvemmat yritykset eivät ole sama kuin ei yrityksiä, ja välilehden tuominen takaisin eteen on tavallinen hetki niiden purskahdukselle.

Minne vikapolitiikka laskeutuu

Asiakkaan estoa arvioidaan silloin, kun yhteyttä yritetään, ei silloin, kun sivu haettiin. Jos tavallinen pääsy on yhä sallittua, uusintayritys voi lähteä fyysisen linkin yli suojaamattomana. Jos käytäntö pitää liikennettä kunnes tunneli palaa, yritys epäonnistuu yhdistämishetkellä ja sivu näyttää virheen, jota se voi yrittää uudelleen muutama sekunti myöhemmin.

Kaksi yksityiskohtaa ratkaisee, kumman saat. Ensimmäinen on asiakkaan tukema valvonta-alue: koko laitteen esto, tunnelisovittimeen rajattu esto tai poikkeuksia sisältävä sääntöryhmä. Toinen on se, osuuko kohde aiemmin lisäämääsi poikkeukseen paikallista tulostinta, captive-portaalia tai suoratoistopalvelua varten.

Sovellustason salaus ei muuta tästä mitään. HTTPS suojaa bitit selaimen ja palvelimen välillä; se ei kerro mitään siitä, mikä liitäntä ne kuljettaa. Sivu voi olla täydellisesti salattu ja lähteä silti väärää polkua, ja juuri sen kapea esto sallii.

Valvottu tarkistus kertakäyttösivulla

Käytä isäntää, jota hallitset, ja sivua, joka ei tee muuta kuin kutsuu sitä, jotta pelissä ei ole oikeita tietoja. Ota päätteeltä näyte polusta ennen katkosta ja sen jälkeen:

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

Aja se tunnelin ollessa ylhäällä, laske sitten tunneli alas ja aja uudelleen. Vastaus julkisesta osoitteesta tunnelin ollessa alhaalla kertoo, että suora polku on auki. Aikakatkaisu tai hylätty yhteys kertoo, että käytäntö pitää. Toista vielä kerran, kun asiakas on yhdistänyt uudelleen, jotta näet tunnelipolun palaavan sen sijaan, että olettaisit sen palanneen.

Selaimessa Verkko-paneeli erottaa kaksi kysymystä. Suodata kohtaan Fetch/XHR ja lue sitten aloittaja-sarake: ajastimen tai skriptin käynnistämä merkintä, jota ennen ei ole kirjattu navigointia, on taustayritys eikä uudelleenlataus. Vertaa sen alkuaikaa hetkeen, jolloin tunneli katkesi. Jos merkintä on yhä vireillä tunnelin ollessa poissa, pyyntö odottaa polkua, jota ei enää ole.

Palvelinpuolen todisteet ovat vahvempia kuin mikään, mitä selain näyttää. Pyyntöloki aikaleimalla ja lähdeosoitteella todistaa, että paketti saapui. Selainmerkinnät voivat sisältää evästeitä, tokeneita ja täydellisiä URL-osoitteita, joten säilytä vain kysymyksesi tarvitsemat kentät ja peitä loput ennen kuin liität ne mihinkään.

Mitä vastauksella tehdään

Jos taustayritykset jatkavat onnistumista tunnelin ollessa alhaalla, esto on kapeampi kuin oletit, ja se aukko kannattaa sulkea ennen kuin uskot asiakkaan arkaluontoiselle työlle. Jos ne epäonnistuvat, käytäntö tekee tehtävänsä ja jäätynyt sivu on kosmeettinen. Kummassakin tapauksessa yhden välilehden sulkeminen ei ole koko laitteen hallinta: muut välilehdet, muut selaimet ja muut sovellukset aikatauluttavat kukin oman työnsä.

Seuraavat askeleet, jotka kannattaa ottaa: luettele, mitkä poikkeukset olet lisännyt ja miksi, vahvista, estääkö asiakas vain tunnelin laajuisen liikenteen vai kaiken liikenteen, ja seuraa yhtä taustapyyntöä alusta loppuun palvelinlokin ollessa auki. Nuo kolme vastausta kattavat suurimman osan siitä, mitä raportti «VPN katkesi ja jokin on yhä yhteydessä» todella sisältää.