VPN падна по средата на страницата: изпращат ли се още фонови заявки?

Разделът все още показва таблото отпреди тунелът да умре. Числата за състоянието замръзват, малък индикатор продължава да се върти, а адресната лента все още носи приложението, което отворихте преди час. Не сте докоснали нищо след прекъсването, но страницата може все още да се опитва да достигне своя сървър по собствен график. Именно това хората пропускат: страница, която само се вижда, и страница, която все още изпраща заявки, изглеждат еднакви отвън и само една от тях се появява в мрежовия журнал.

Работа, която страницата започва без вас

Четири механизма държат зареден документ зает. Повтарящ се таймер може да пуска отново заявка за състояние на всеки няколко секунди. Fetch може да се задейства, когато разделът отново стане видим, след като се върнете към него. Жив канал, изграден на WebSocket или събития от сървъра, може да опита повторно свързване по собствен график за отстъпване. Обслужващ работник, регистриран от сайта, може да се събуди за поставена в опашка синхронизация дори когато пред вас няма раздел.

Нито един от тях не се нуждае от клик и нито един не презарежда документа. Адресната лента, позицията на превъртане и изобразените стойности остават там, където са били. Променя се само мрежовата страна: всеки нов опит е свежо решение, взето в момента, в който започва.

Това разграничение има значение, защото видимата страница се съхранява локално. Вече нарисуваните пиксели не казват нищо за това дали следващата заявка е успяла. Замръзнала графика с индикатор е обичайният вид на страница, чиито заявки сега се провалят. Четенето на екрана ви казва какво е казал сървърът преди минути, а не какво прави браузърът сега.

Защо по-ранното зареждане на страницата не държи маршрут

Нищо в зареждането на страницата не свързва документа с тунела. Маршрутизацията се решава за всеки пакет, в момента на изпращане, от таблицата, която съществува, когато пакетът напуска. Когато интерфейсът на тунела изчезне, това търсене вече не съответства на маршрута през тунела. То или пропада към физическия адаптер, или не намира нищо, в зависимост от това какво е оставил клиентът.

Повтарящите се обратни извиквания са обикновени планирани задачи. Разделът за таймери в стандарта HTML описва как се поставят в опашка и третира интервала като минимално закъснение, а не като обещание за точен ритъм, така че фоновият раздел може да отправя заявки много по-рядко, отколкото иска кодът му. По-малко опити не е същото като никакви опити, а връщането на раздел на преден план е обичаен момент за изблик от тях.

Къде се приземява политиката при отказ

Блокирането на клиента се оценява, когато се опита връзка, а не когато страницата е била изтеглена. Ако обикновеният достъп все още е разрешен, повторният опит може да излезе през физическата връзка в чист вид. Ако политиката задържа този трафик, докато тунелът се върне, опитът се проваля в момента на свързване и страницата показва грешка, която може да опита отново след няколко секунди.

Две подробности решават кой от тези ще получите. Първата е обхватът на прилагане, който клиентът поддържа: блок за цялото устройство, блок, ограничен до адаптера на тунела, или набор от правила с изключения. Втората е дали дестинацията попада в изключение, което сте добавили по-рано за локален принтер, портал за улавяне или услуга за стрийминг.

Шифроването на ниво приложение не променя нищо от това. HTTPS защитава байтовете между браузъра и сървъра; той не казва нищо за това кой интерфейс ги носи. Страницата може да е идеално шифрована и пак да излезе по грешния път и точно това позволява тесен блок.

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

Използвайте хост, който контролирате, и страница, която не прави нищо друго освен да го вика, така че никакви реални данни да не са в игра. От терминал вземете проба от пътя преди и след прекъсването:

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

Пуснете го с включен тунел, след това изключете тунела и го пуснете отново. Отговор от публичен адрес, докато тунелът е изключен, ви казва, че директният път е отворен. Изтичане на времето или отказана връзка ви казва, че политиката държи. Повторете още веднъж, след като клиентът се свърже отново, за да видите, че пътят през тунела се връща, вместо да предполагате, че е станало.

В браузъра панелът Мрежа разделя двата въпроса. Филтрирайте до Fetch/XHR, след което прочетете колоната на инициатора: запис, стартиран от таймер или скрипт, без регистрирана навигация преди него, е фонов опит, а не презареждане. Сравнете началния му час с момента, в който тунелът падна. Ако записът все още е в изчакване, когато тунелът го няма, заявката чака път, който вече не съществува.

Доказателствата от страна на сървъра са по-силни от всичко, което браузърът показва. Журнал на заявките с времева марка и адрес на източника доказва, че пакетът е пристигнал. Записите в браузъра могат да носят бисквитки, токени и пълни URL адреси, така че запазете само полетата, които въпросът ви изисква, и заличате останалите, преди да ги поставите някъде.

Какво да правите с отговора

Ако фоновите опити продължават да успяват, докато тунелът е изключен, блокът е по-тесен, отколкото сте предполагали, и тази празнина си заслужава да бъде затворена, преди да се доверите на клиента за чувствителна работа. Ако се провалят, политиката си върши работата и замръзналата страница е козметична. Във всеки случай затварянето на един раздел не е контрол за цялото устройство: други раздели, други браузъри и други приложения всеки планира собствената си работа.

Стъпки, които си струват: избройте кои изключения сте добавили и защо, потвърдете дали клиентът блокира само трафик в обхвата на тунела или целия трафик, и наблюдавайте една фонова заявка от началото до края с отворен сървърен журнал. Тези три отговора покриват голяма част от това, което всъщност съдържа доклад от вида „VPN падна и нещо още е свързано“.