VPN паѓа кога екранот се исклучува: кој животен циклус?
Заклучен екран може да го суспендира клиентот, да дозволи мапирањето да истече или да убие сесија на апликација. Еден контролиран тест ги раздвојува пред каква било промена на поставките.
Преносот запира во моментот кога екранот се затемнува, а значката следи неколку секунди подоцна. Три различни работи ја создаваат таа слика: клиентскиот процес се ограничува, патеката останува неактивна и го губи своето мапирање, или апликацијата губи сесија што тунелот никогаш не ја забележал. Секоја има свои докази, и секоја поправка припаѓа на различен слој. Редоследот подолу ги раздвојува со еден контролиран тест наместо преглед на сите поставки.
Три дефекти што изгледаат идентично
Ограничен позадински процес престанува да испраќа keepalive, и другата страна на крајот го прогласува тунелот за мртов. Неактивно мапирање на патеката може да истече додека уредот спие, така што повратниот сообраќај никогаш не стигнува до клиент што е сѐ уште сосема жив. Апликацијата може да ја загуби сопствената врска додека тунелот стои, што создава дијалог за грешка со здрава VPN значка зад него. Од гледна точка на корисникот, сите три се читаат како VPN што паднал при исклучување на екранот.
Разликата е важна зашто решенијата во практиката си противречат. Ослободувањето на клиентот од енергетските ограничувања го поправа првиот случај и не прави ништо за истечено мапирање. Продолжувањето на keepalive го поправа вториот и ја троши батеријата во третиот, каде што првично ништо мрежно не било погрешно.
Споредете активно и неактивно под контрола
Држете сѐ константно: ист уред, иста мрежа, иста крајна точка, иста апликација. Заклучете го екранот на краток фиксен интервал и забележете три набљудувања: дали клиентот пријавува прекин, дали ново барање работи при отклучување и дали постојниот пренос продолжи. Потоа повторете со вклучен keepalive или периодично барање и споредете ги двете извршувања. Една променета променлива меѓу две извршувања вреди повеќе од една недела анегдотски извештаи.
Времето припаѓа во записот. Пад по деведесет секунди мириса на мапирање или интервал на keepalive, додека пад во моментот на заклучување укажува на суспензија на процесот. Запишете и го активирачот и интервалот, зашто следниот обид треба нешто со што ќе се спореди.
Прочитајте ја позадинската политика на платформата
На Android животниот циклус на VPN услугата е дел од платформата, а always-on и block-without-VPN се одделни прекинувачи со одделни ефекти. Клиент што не е always-on може да биде запрен кога системот враќа ресурси, и ниту една поставка во апликацијата тоа не го менува. iOS применува свои позадински ограничувања на давателот на тунелот, и документираното однесување се разликува од десктоп демон што едноставно продолжува да работи. Читајте ја документацијата на платформата за соодветната компонента, а не општ водич за оптимизација на батеријата.
Управуваните уреди додаваат уште еден слој. Политиката може да ја надмине личната поставка, така што промена што изгледа дека работи се враќа при следното освежување на политиката. Користете го поддржаниот процес за исклучок на организацијата ако барањето е вистинско, и запишете зошто исклучокот постои.
Што прави уредот по будењето
Автоматското повторно поврзување не е исто како блокирање на сообраќајот за време на празнината. Проверете и двете: дали тунелот се враќа и дали апликација што се обидела да испрати за време на празнината излегла незаштитена. Клиент што се поврзува повторно за две секунди, но во првата пропушта DNS барање, има погрешна политика за откажување за работен уред. Тестирајте со безопасни барања и одредиште што го контролирате.
Восстановувањето на апликацијата е третото прашање. Тунел што се враќа не поправа SSH сесија што истекла, и корисниците често го пријавуваат тој губиток на сесија како дефект на VPN. Држете ги заедно во извештајот активирачот, верзијата на клиентот и точното време, зашто таа комбинација раздвојува предвидлив животен циклус на исклучување екран од сервер што паѓа независно од уредот.