VPN паѓа кога екранот ќе се затемни: заклучување, исклучување или мирување?
Заклучена сесија, затемнет екран и машина во мирување се три различни настани. Поврзете ги со journalctl пред да го обвините механизмот за одржување на врската на VPN.
Кога некој вели дека VPN умрел кога екранот се затемнил, првото корисно прашање е кој од трите настани навистина се случил: сесијата се заклучила, панелот се исклучил или целата машина заспала. Тоа се одделни механизми на одделни тајмери и само еден од нив може целосно да спречи закажување на процес. Поминете ги проверките подолу по ред. Запрете на првата што одговара на прашањето, зашто секоја следна одговара на нешто друго.
Прва проверка: одделете го заклучувањето од затемнувањето и од спиењето
Заклучувањето менува кој смее да ја користи сесијата; композиторот продолжува да црта, мрежниот стек продолжува да работи, а VPN клиентот не забележува ништо. Затемнувањето на екранот го исклучува панелот по период на неактивност и ја остава машината целосно будна. Мирувањето ги запира процесорите, што значи дека ниту еден процес во корисничкиот простор не се закажува, па никакво одржување на врската не може да се активира, колку и краток да е интервалот.
| Event | What it stops | Can it kill the tunnel? |
|---|---|---|
| Session lock | Input to your session | No |
| Display blank | The panel | No |
| Suspend to RAM | CPU scheduling, hence every process | Yes, and silently |
| Hibernate | Everything, with state written to disk | Yes |
Токму оваа табела е причината зошто „екранот се затемни“ не е дијагноза. Десктоп поставен да се затемни по пет минути и да заспие по триесет ќе покаже темен екран во шестата минута со сосема здрав тунел. Дефектот во триесеттата минута е друг настан со друго решение, а двете изгледаат исто од другата страна на собата.
Втора проверка: ставете ги настаните за напојување и мрежа на една временска линија
Читајте го дневникот за ограничен прозорец, а не за целото подигнување, и вклучете го и менаџерот за најава и сопственикот на врската:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list
Првата команда ги прикажува барањата за мирување, разбудувањето и мрежните премини што следеле. Втората прикажува што моментално држи инхибиторна брава, што ви кажува дали нешто намерно го блокира мирувањето и кој програм е тоа. Прилагодете ги имињата на единиците ако сопственикот на вашата врска не е NetworkManager, и запомнете дека читањето единица на друг корисник или системскиот дневник зависи од локалната политика.
Редот што недостасува не е негативен резултат. Ако дневникот на избраната единица не е видлив за вашата сметка, отсуството на запис за мирување не докажува ништо, а заклучокот „никогаш не спиело“ од празен филтер е патот по кој луѓето поминуваат една недела прилагодувајќи одржување на врската.
Трета проверка: ако заспало, одлучете дали тоа било намерно
Штом преминот во мирување се појави на временската линија, прашањето се менува од „зошто VPN се скрши“ во „дали машината воопшто требаше да спие“. На преносен компјутер одговорот е често да, а прекинот на тунелот е очекувано однесување од кое клиентот треба да се опорави при разбудување. На работна станица што треба да остане достапна, политиката за мирување е она што треба да се смени. За да одлучите на која од овие две машини гледате, потребно е едно прашање, и тоа не е прашање на кое дневникот може да одговори наместо вас.
Сменете ја преку контролите што ѝ припаѓаат на најавената сесија, или преку механизам поддржан од администраторот ако барањето важи за целата машина. Уредувањето на поставка на менаџерот за екран додека сте најавени со друга сметка не е исто дејство и ќе изгледа како да работело до почетокот на следната сесија. Целосното исклучување на управувањето со напојување е широка прва реакција што чини траење на батеријата и го крие вистинското прашање за политиката.
Четврта проверка: ако останало будно, погледнете ја мрежата и клиентот
Будна машина што го изгубила тунелот има една од три приказни: пристапната мрежа паднала, VPN клиентот запрел или се рестартирал, или серверската страна дозволила асоцијацијата да истече додека клиентот продолжувал да верува дека е поврзан. Споредете ги временските ознаки на основниот настан на врската со настанот на тунелот и бидете прецизни за тоа кој дошол прв.
Потоа тестирајте го патот за опоравување одделно од првобитната сесија. Ново барање преку обновениот тунел може да успее додека долготрајната сесија на апликацијата отворена пред прекинот останува скршена, зашто апликацијата држи застарен сокет или кеширана адреса. Тоа е проблем на апликацијата, а не доказ дека тунелот не се вратил.
Што содржи корисен извештај
Запишете ја низата со временски ознаки и сопственици: кога се заклучила сесијата, кога се затемнил екранот, дали е запишано барање за мирување, кога врската паднала и се вратила, кога тунелот го сменил состојбата и што всушност направила апликацијата. Секоја ставка има сопственик, па секоја ставка може да ѝ се предаде на вистинската личност наместо да стане општа жалба за Linux.
Ако недостасува некој од овие редови, тоа е следното нешто што треба да се измери, а не следното што треба да се смени. Временска линија со празнина е поинформативна од промена на поставки направена по чувство.