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

Три повреди, които изглеждат еднакво

Ограничен фонов процес спира да изпраща keepalive и отсрещната страна в крайна сметка обявява тунела за мъртъв. Неактивно съпоставяне по пътя може да изтече, докато устройството спи, така че обратният трафик така и не достига до клиент, който все още е напълно жив. Приложението може да загуби собствената си връзка, докато тунелът остава вдигнат, което дава диалог за грешка със здрава VPN значка зад него. От гледна точка на потребителя и трите се четат като паднал VPN при изключване на екрана.

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

Сравнете активен и неактивен режим при контролирани условия

Дръжте всичко постоянно: същото устройство, същата мрежа, същата крайна точка, същото приложение. Заключете екрана за кратък фиксиран интервал и запишете три наблюдения: дали клиентът съобщава за прекъсване, дали ново искане работи при отключване и дали съществуващият пренос е продължил. След това повторете с работещ keepalive или периодично искане и сравнете двете пускания. Една променена величина между две пускания е по-добра от седмица анекдотични доклади.

Времето принадлежи в записа. Падане след деветдесет секунди мирише на съпоставяне или на интервал на keepalive, докато падане в момента на заключване сочи към спиране на процеса. Запишете и задействащото условие, и интервала, защото следващият опит се нуждае от нещо за сравнение.

Прочетете фоновата политика на платформата

На Android жизненият цикъл на VPN услугата е част от платформата, а always-on и block-without-VPN са отделни превключватели с отделни ефекти. Клиент, който не е always-on, може да бъде спрян, когато системата си възвърне ресурси, и никоя настройка в приложението не променя това. iOS прилага собствени фонови ограничения към доставчика на тунела и документираното поведение се различава от демон на настолен компютър, който просто продължава да работи. Четете документацията на платформата за въпросния компонент, а не общо ръководство за оптимизиране на батерията.

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

Какво прави устройството след събуждане

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

Възстановяването на приложението е третият въпрос. Тунел, който се връща, не поправя SSH сесия, изтекла по време, и потребителите често съобщават тази загуба на сесия като повреда на VPN. Дръжте задействащото условие, версията на клиента и точното време заедно в доклада, защото тази комбинация разграничава предвидим жизнен цикъл при изключване на екрана от сървър, който се проваля независимо от устройството.

Подобни статии