VPN falis meze de la paĝo: ĉu fonaj petoj ankoraŭ eliras?

La langeto ankoraŭ montras la panelon de antaŭ ol la tunelo mortis. Statusaj nombroj frostiĝas, malgranda ŝpinilo daŭre turniĝas, kaj la adresbreto ankoraŭ portas la aplikaĵon, kiun vi malfermis antaŭ horo. Vi tuŝis nenion post la interrompo, tamen la paĝo eble ankoraŭ provas atingi sian servilon laŭ sia propra horaro. Tiu estas la parto, kiun homoj maltrafas: paĝo, kiu nur estas videbla, kaj paĝo, kiu ankoraŭ sendas petojn, aspektas idente de ekstere, kaj nur unu el ili aperas en reta protokolo.

Laboro, kiun paĝo komencas sen vi

Kvar mekanismoj tenas ŝarĝitan dokumenton okupata. Ripeta tempigilo povas relanĉi statusan alvokon ĉiujn kelkajn sekundojn. Fetch povas ekbruli, kiam la langeto denove fariĝas videbla post kiam vi resaltas al ĝi. Viva kanalo konstruita sur WebSocket aŭ servile senditaj eventoj povas provi rekonekton laŭ sia propra retiriĝa horaro. Serva laboranto registrita de la retejo povas vekiĝi por atendata sinkronigo eĉ kiam neniu langeto estas antaŭ vi.

Neniu el tiuj bezonas klakon, kaj neniu el ili reŝarĝas la dokumenton. La adresbreto, la rula pozicio kaj la bildigitaj valoroj ĉiuj restas tie, kie ili estis. Tio, kio ŝanĝiĝas, estas nur la reta flanko: ĉiu nova provo estas freŝa decido farita en la momento, kiam ĝi komenciĝas.

Tiu distingo gravas, ĉar la videbla paĝo estas konservita loke. Jam pentritaj rastrumeroj diras nenion pri tio, ĉu la sekva peto sukcesis. Frostigita diagramo kun ŝpinilo estas la ordinara aspekto de paĝo, kies petoj nun malsukcesas. Legi la ekranon diras al vi, kion la servilo diris antaŭ minutoj, ne kion la retumilo faras nun.

Kial la pli frua paĝa ŝarĝo ne tenas itineron

Nenio en la paĝa ŝarĝo ligas la dokumenton al la tunelo. Enkursigo estas solvita po paketo, en la senda momento, el la tabelo, kiu ekzistas kiam la paketo forlasas. Kiam la tunela interfaco malaperas, tiu serĉo ne plu kongruas kun la tunela itinero. Ĝi aŭ falas al la fizika adaptilo aŭ trovas nenion, depende de tio, kion la kliento lasis malantaŭ si.

Ripetaj retroalvokoj estas ordinaraj planitaj taskoj. La tempigila sekcio de la HTML-normo priskribas, kiel ili estas enigitaj en vicordo, kaj traktas la intervalon kiel minimuman prokraston anstataŭ promeson de preciza ritmo, do fona langeto povas enketi multe malpli ofte ol ĝia kodo postulas. Malpli da provoj ne samas al neniuj provoj, kaj reporti langeton al la malfono estas ofta momento por eksplodo de ili.

Kien la malsukcesa politiko alteriĝas

La bloko de la kliento estas taksata, kiam oni provas konekton, ne kiam la paĝo estis akirita. Se ordinara aliro ankoraŭ estas permesata, la reprovo povas eliri tra la fizika ligilo malkaŝe. Se la politiko retenas tiun trafikon ĝis la tunelo revenos, la provo malsukcesas en la konekta momento kaj la paĝo montras eraron, kiun ĝi povas reprovi kelkajn sekundojn poste.

Du detaloj decidas, kiun el tiuj vi ricevos. La unua estas la plenumskopo, kiun la kliento subtenas: bloko por la tuta aparato, bloko limigita al la tunela adaptilo, aŭ regularo kun esceptoj. La dua estas, ĉu la celo falas en escepton, kiun vi antaŭe aldonis por loka printilo, kaptita portalo aŭ fluiga servo.

Ĉifrado je aplikada nivelo ŝanĝas nenion el tio. HTTPS protektas la bitokojn inter retumilo kaj servilo; ĝi diras nenion pri tio, kiu interfaco portas ilin. Paĝo povas esti perfekte ĉifrita kaj tamen eliri tra la malĝusta vojo, kaj ĝuste tion permesas mallarĝa bloko.

Kontrolita kontrolo per forĵetebla paĝo

Uzu gastiganton, kiun vi kontrolas, kaj paĝon, kiu faras nenion krom voki ĝin, por ke neniuj realaj datumoj estu en ludo. El terminalo, prenu specimenon de la vojo antaŭ kaj post la interrompo:

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

Rulu ĝin kun la tunelo supren, poste mallevu la tunelon kaj rulu ĝin denove. Respondo de publika adreso dum la tunelo estas malsupren diras al vi, ke la rekta vojo estas malfermita. Tempolimo aŭ rifuzita konekto diras al vi, ke la politiko tenas. Ripetu ankoraŭ unufoje post kiam la kliento rekonektiĝos, por ke vi vidu la tunelan vojon reveni anstataŭ supozi, ke ĝi faris.

En la retumilo, la Reta panelo apartigas la du demandojn. Filtru al Fetch/XHR, poste legu la kolumnon de iniciatinto: ero startigita de tempigilo aŭ skripto, kun neniu navigado registrita antaŭ ĝi, estas fona provo anstataŭ reŝarĝo. Komparu ĝian startan tempon kun la momento, kiam la tunelo falis. Se la ero ankoraŭ atendas, kiam la tunelo forestas, la peto atendas vojon, kiu ne plu ekzistas.

Pruvoj ĉe la servila flanko estas pli fortaj ol ĉio, kion la retumilo montras. Petprotokolo kun tempstampo kaj fonta adreso pruvas, ke la paketo alvenis. Retumilaj eroj povas porti kuketojn, ĵetonojn kaj plenajn URL-ojn, do konservu nur la kampojn, kiujn via demando bezonas, kaj kaŝu la reston antaŭ ol alglui ilin ie ajn.

Kion fari kun la respondo

Se fonaj provoj daŭre sukcesas dum la tunelo estas malsupren, la bloko estas pli mallarĝa ol vi supozis, kaj tiu breĉo indas fermiĝi antaŭ ol vi fidos la klienton por sentema laboro. Se ili malsukcesas, la politiko faras sian taskon kaj la frostigita paĝo estas kosmetika. Ĉiel ajn, fermi unu langeton ne estas tut-aparata regado: aliaj langetoj, aliaj retumiloj kaj aliaj aplikaĵoj ĉiu planas sian propran laboron.

Sekvaj paŝoj indaj je entrepreno: listigu, kiujn esceptojn vi aldonis kaj kial, konfirmu, ĉu la kliento blokas nur tunel-skopajn trafikon aŭ ĉiun trafikon, kaj observu unu fonan peton de komenco ĝis fino kun la servila protokolo malfermita. Tiuj tri respondoj kovras la plejparton de tio, kion raporto «la VPN falis kaj io ankoraŭ konektiĝas» efektive enhavas.