VPN је пао насред странице: да ли позадински захтеви и даље излазе?

Картица и даље приказује контролну таблу од пре него што је тунел умро. Бројеви стања се замрзавају, мали спинер наставља да се обрће, а адресна трака још носи апликацију коју сте отворили пре сат времена. Нисте ништа дирали након прекида, а ипак страница можда још покушава да дође до свог сервера по сопственом распореду. То је део који људи пропуштају: страница која је само видљива и страница која још шаље захтеве споља изгледају исто, а само једна од њих се појављује у мрежном дневнику.

Посао који страница започне без вас

Четири механизма држе учитан документ заузетим. Понављајући тајмер може поново да покрене позив стања сваких неколико секунди. Fetch може да се активира када картица поново постане видљива након што се вратите на њу. Живи канал изграђен на WebSocket-у или на догађајима које шаље сервер може да покуша поновно повезивање по сопственом распореду одустајања. Сервисни радник који је страница регистровала може да се пробуди за синхронизацију у реду чекања чак и када нема картице пред вама.

Ниједан од њих не тражи клик и ниједан поново не учитава документ. Адресна трака, положај померања и приказане вредности остају тамо где су били. Мења се само мрежна страна: сваки нови покушај је свежа одлука донета у тренутку када почиње.

Та разлика је важна јер се видљива страница чува локално. Већ нацртани пиксели не говоре ништа о томе да ли је следећи захтев успео. Замрзнути графикон са спинером уобичајен је изглед странице чији захтеви сада не успевају. Читање екрана говори вам шта је сервер рекао пре неколико минута, а не шта прегледач ради сада.

Зашто раније учитавање странице не држи руту

Ништа у учитавању странице не везује документ за тунел. Усмеравање се решава по пакету, у време слања, из табеле која постоји када пакет излази. Када тунелски интерфејс нестане, та претрага више не одговара тунелској рути. Или пропада на физички адаптер или не налази ништа, у зависности од тога шта је клијент оставио за собом.

Понављајући повратни позиви су обични заказани задаци. Одељак стандарда HTML о тајмерима описује како се стављају у ред и интервал третира као минимално кашњење, а не као обећање тачног ритма, па позадинска картица може да анкетира много ређе него што њен код тражи. Мање покушаја није исто што и никакви покушаји, а враћање картице у први план уобичајен је тренутак за њихов излив.

Где политика квара завршава

Блок клијента процењује се када се покуша веза, а не када је страница добављена. Ако је обичан приступ још дозвољен, поновни покушај може да изађе преко физичке везе отворено. Ако политика задржава тај саобраћај док се тунел не врати, покушај не успева у тренутку повезивања и страница приказује грешку коју може поново да покуша неколико секунди касније.

Два детаља одлучују који ћете од тога добити. Први је обим примене који клијент подржава: блок за цео уређај, блок ограничен на тунелски адаптер или скуп правила са изузецима. Други је да ли одредиште пада унутар изузетка који сте раније додали за локални штампач, captive портал или услугу стримовања.

Шифровање на нивоу апликације не мења ништа од овога. HTTPS штити бајтове између прегледача и сервера; не говори ништа о томе који интерфејс их носи. Страница може бити савршено шифрована и ипак изаћи погрешним путем, а управо то уски блок дозвољава.

Контролисана провера са једнократном страницом

Користите хост који контролишете и страницу која не ради ништа осим што га позива, тако да у игри нема стварних података. Из терминала узмите узорак пута пре и после прекида:

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

Покрените то са укљученим тунелом, затим искључите тунел и покрените поново. Одговор са јавне адресе док је тунел искључен говори вам да је директни пут отворен. Истек времена или одбијена веза говори вам да политика држи. Поновите још једном након што се клијент поново повеже, како бисте видели да се тунелски пут враћа, уместо да претпостављате да јесте.

У прегледачу мрежни панел раздваја два питања. Филтрирајте на Fetch/XHR, затим прочитајте колону иницијатора: унос који је покренуо тајмер или скрипта, без забележене навигације пре њега, позадински је покушај, а не поновно учитавање. Упоредите његово време почетка са тренутком када је тунел пао. Ако је унос још на чекању док тунела нема, захтев чека пут који више не постоји.

Докази на страни сервера јачи су од свега што прегледач приказује. Дневник захтева са временском ознаком и изворном адресом доказује да је пакет стигао. Уноси у прегледачу могу носити колачиће, токене и пуне URL-ове, зато задржите само поља која ваше питање треба и редагујте остало пре него што их залепите било где.

Шта учинити са одговором

Ако позадински покушаји настављају да успевају док је тунел искључен, блок је ужи него што сте претпоставили, а ту празнину вреди затворити пре него што клијенту поверите осетљив рад. Ако не успевају, политика ради свој посао и замрзнута је страница козметичка. У сваком случају, затварање једне картице није контрола на нивоу уређаја: друге картице, други прегледачи и друге апликације сваки планирају свој посао.

Следећи кораци вредни предузимања: наведите које сте изузетке додали и зашто, потврдите да ли клијент блокира само саобраћај у тунелском обиму или сав саобраћај, и посматрајте један позадински захтев од почетка до краја са отвореним дневником сервера. Та три одговора покривају већину онога што извештај „VPN је пао и нешто је још повезано” заправо садржи.