Napatid ang VPN sa gitna ng pahina: lumalabas pa ba ang mga kahilingan sa background?
Ang pahinang iniwang bukas ay patuloy na nagtatanong, muling kumokonekta at nagsi-sync pagkatapos mamatay ang tunnel. Tingnan kung aling mga pagtatangka ang lumalabas pa at paano ito patunayan.
Ipinapakita pa rin ng tab ang dashboard mula bago mamatay ang tunnel. Nagyeyelo ang mga numero ng status, patuloy na umiikot ang maliit na spinner, at dala pa rin ng address bar ang app na binuksan mo isang oras na ang nakalipas. Wala kang hinawakan pagkatapos ng pagkaputol, gayunpaman maaaring sinusubukan pa rin ng pahina na maabot ang server nito ayon sa sarili nitong iskedyul. Iyon ang bahaging hindi napapansin ng mga tao: ang pahinang nakikita lamang at ang pahinang nagpapadala pa ng mga kahilingan ay magkamukha mula sa labas, at isa lamang sa kanila ang lumalabas sa log ng network.
Trabahong sinisimulan ng pahina nang wala ka
Apat na mekanismo ang nagpapanatiling abala sa isang na-load na dokumento. Ang umuulit na timer ay maaaring magpatakbo muli ng tawag sa status tuwing ilang segundo. Maaaring pumutok ang fetch kapag muling nakita ang tab pagkatapos mong bumalik dito. Ang live na channel na itinayo sa WebSocket o mga event na ipinapadala ng server ay maaaring magtangkang muling kumonekta ayon sa sarili nitong backoff na iskedyul. Ang service worker na inirehistro ng site ay maaaring magising para sa isang sync na nasa pila kahit walang tab sa harap mo.
Wala sa mga ito ang nangangailangan ng click, at wala sa mga ito ang muling naglo-load ng dokumento. Ang address bar, posisyon ng scroll at mga halagang na-render ay nananatili sa dati nilang lugar. Ang nagbabago lamang ay ang panig ng network: bawat bagong pagtatangka ay isang sariwang desisyon na ginawa sa sandaling ito ay nagsimula.
Mahalaga ang pagkakaibang iyon dahil ang nakikitang pahina ay naka-imbak nang lokal. Ang mga pixel na naipinta na ay walang sinasabi tungkol sa kung nagtagumpay ang susunod na kahilingan. Ang isang nakapirming chart na may spinner ay ang karaniwang anyo ng pahinang binibigo na ngayon ang mga kahilingan. Ang pagbabasa ng screen ay nagsasabi sa iyo kung ano ang sinabi ng server ilang minuto ang nakalipas, hindi kung ano ang ginagawa ng browser ngayon.
Bakit hindi hawak ng naunang pag-load ng pahina ang isang ruta
Walang anumang bagay sa pag-load ng pahina na nagbibigkis sa dokumento sa tunnel. Ang routing ay nireresolba bawat packet, sa oras ng pagpapadala, mula sa talahanayang umiiral kapag umaalis ang packet. Kapag nawala ang interface ng tunnel, hindi na tumutugma ang paghahanap na iyon sa ruta ng tunnel. Bumabagsak ito sa pisikal na adapter o wala itong mahanap, depende sa iniwan ng kliyente.
Ang mga umuulit na callback ay ordinaryong naka-iskedyul na gawain. Inilalarawan ng seksyon ng mga timer ng HTML standard kung paano sila pumipila at tinatrato ang interval bilang pinakamababang pagkaantala sa halip na pangako ng eksaktong ritmo, kaya ang isang background na tab ay makakapagtaka nang mas madalang kaysa hinihingi ng code nito. Ang mas kaunting pagtatangka ay hindi kapareho ng walang pagtatangka, at ang pagbalik ng tab sa harap ay karaniwang sandali para sa pagsabog nila.
Saan lumalapag ang patakaran sa pagkabigo
Ang pag-block ng kliyente ay tinatasa kapag may sinusubukang koneksyon, hindi kapag nakuha ang pahina. Kung pinapayagan pa rin ang ordinaryong access, maaaring lumabas ang muling pagtatangka sa pisikal na link nang lantad. Kung hinahawakan ng patakaran ang trapik na iyon hanggang bumalik ang tunnel, nabibigo ang pagtatangka sa sandali ng pagkonekta at nagpapakita ang pahina ng error na maaaring subukan muli pagkalipas ng ilang segundo.
Dalawang detalye ang nagtatakda kung alin sa mga ito ang makukuha mo. Ang una ay ang saklaw ng pagpapatupad na sinusuportahan ng kliyente: pag-block sa buong device, pag-block na limitado sa tunnel adapter, o set ng mga patakaran na may mga pagbubukod. Ang pangalawa ay kung ang destinasyon ay nasa loob ng pagbubukod na idinagdag mo kanina para sa lokal na printer, captive portal o streaming service.
Ang encryption sa antas ng application ay walang binabago sa alinman sa mga ito. Pinoprotektahan ng HTTPS ang mga byte sa pagitan ng browser at server; wala itong sinasabi tungkol sa kung aling interface ang nagdadala sa kanila. Ang isang pahina ay maaaring perpektong naka-encrypt at lumabas pa rin sa maling landas, at iyon ang eksaktong pinapayagan ng makitid na pag-block.
Isang kontroladong pagsusuri gamit ang itatapong pahina
Gumamit ng host na kontrolado mo at pahinang walang ginagawa kundi tawagan ito, para walang totoong datos na nasa laro. Mula sa terminal, kumuha ng sample ng landas bago at pagkatapos ng pagkaputol:
curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/pingPatakbuhin ito habang nakataas ang tunnel, pagkatapos ibaba ang tunnel at patakbuhin muli. Ang sagot mula sa pampublikong address habang nakababa ang tunnel ay nagsasabi sa iyo na bukas ang direktang landas. Ang timeout o tinanggihang koneksyon ay nagsasabi sa iyo na hinahawakan ito ng patakaran. Ulitin isa pang beses pagkatapos muling kumonekta ang kliyente, para makita mong bumabalik ang landas ng tunnel sa halip na ipagpalagay ito.
Sa browser, hinihiwalay ng panel ng Network ang dalawang tanong. I-filter sa Fetch/XHR, pagkatapos basahin ang column ng initiator: ang entry na sinimulan ng timer o script, na walang navigation na naitala bago ito, ay pagtatangka sa background at hindi muling pag-load. Ihambing ang oras ng pagsisimula nito sa sandaling bumagsak ang tunnel. Kung nakabinbin pa rin ang entry kapag wala na ang tunnel, naghihintay ang kahilingan sa landas na wala na.
Ang ebidensiya sa panig ng server ay mas malakas kaysa sa anumang ipinapakita ng browser. Ang log ng mga kahilingan na may timestamp at source address ay nagpapatunay na dumating ang packet. Ang mga entry sa browser ay maaaring magdala ng cookies, token at buong URL, kaya itago lamang ang mga field na kailangan ng iyong tanong at i-redact ang iba bago ito i-paste kahit saan.
Ano ang gagawin sa sagot
Kung patuloy na nagtatagumpay ang mga pagtatangka sa background habang nakababa ang tunnel, ang pag-block ay mas makitid kaysa inaasahan mo, at sulit na isara ang puwang na iyon bago mo ipagkatiwala ang kliyente sa sensitibong trabaho. Kung nabibigo sila, ginagawa ng patakaran ang trabaho nito at ang nakapirming pahina ay kosmetiko lamang. Alinman sa dalawa, ang pagsara ng isang tab ay hindi kontrol sa buong device: ang ibang tab, ibang browser at ibang application ay nag-iiskedyul ng kani-kanilang trabaho.
Mga susunod na hakbang na sulit gawin: ilista ang mga pagbubukod na idinagdag mo at bakit, kumpirmahin kung hinaharang ng kliyente ang trapik sa saklaw ng tunnel lamang o lahat ng trapik, at panoorin ang isang kahilingan sa background mula simula hanggang dulo nang bukas ang log ng server. Ang tatlong sagot na iyon ay sumasaklaw sa karamihan ng aktwal na nilalaman ng ulat na «napatid ang VPN at may nakakonekta pa».