VPN пада, когато екранът угасне: заключване, затъмняване или заспиване?

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

Първа проверка: отделете заключването от затъмняването и от заспиването

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

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

Втора проверка: поставете събитията за захранване и мрежа на една времева линия

Четете журнала за ограничен прозорец, а не за цялото зареждане, и включете както мениджъра за вход, така и собственика на връзката:

journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list

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

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

Трета проверка: ако е заспало, решете дали това е било умишлено

Щом преходът към сън се появи на времевата линия, въпросът се променя от „защо VPN се счупи“ на „трябвало ли е машината изобщо да спи“. На лаптоп отговорът често е да и прекъсването на тунела е очаквано поведение, от което клиентът трябва да се възстанови при събуждане. На работна станция, която трябва да остане достъпна, това, което трябва да се промени, е политиката за сън. Да решите към коя от тези две машини гледате, изисква един въпрос и това не е въпрос, на който журналът може да отговори вместо вас.

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

Четвърта проверка: ако е останало будно, погледнете мрежата и клиента

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

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

Какво съдържа полезен доклад

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

Ако някой от тези редове липсва, това е следващото нещо за измерване, а не следващото нещо за промяна. Времева линия с празнина е по-информативна от промяна на настройки, направена по догадка.