VPN pārtrūkst, kad ekrāns kļūst tumšs: bloķēšana, izslēgšana vai miegs?
Bloķēta sesija, izslēgts ekrāns un miegā esoša iekārta ir trīs dažādi notikumi. Sasaistiet tos ar journalctl, pirms vainojat VPN savienojuma uzturēšanas mehānismu.
Kad kāds saka, ka VPN nomira, kad ekrāns kļuva tumšs, pirmais noderīgais jautājums ir, kurš no trim notikumiem patiešām notika: sesija tika bloķēta, panelis izslēdzās vai visa iekārta aizmiga. Tie ir atsevišķi mehānismi ar atsevišķiem taimeriem, un tikai viens no tiem var pilnībā neļaut procesam tikt ieplānotam. Izstaigājiet zemāk esošās pārbaudes pēc kārtas. Apstājieties pie pirmās, kas atbild uz jautājumu, jo katra nākamā pārbaude atbild uz kaut ko citu.
Pirmā pārbaude: atdaliet bloķēšanu no izslēgšanas un no miega
Bloķēšana maina, kam ir atļauts izmantot sesiju; kompozitors turpina zīmēt, tīkla steks turpina darboties, un VPN klients neko nepamana. Ekrāna izslēgšana izslēdz paneli pēc dīkstāves intervāla un atstāj iekārtu pilnīgi nomodā. Miegs aptur procesorus, kas nozīmē, ka lietotāja telpā netiek ieplānots neviens process, tāpēc neviens savienojuma uzturēšanas signāls nevar iedarboties, lai cik īsu intervālu jūs iestatītu.
| 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 |
Tieši šī tabula ir iemesls, kāpēc „ekrāns kļuva tumšs“ nav diagnoze. Darbvirsma, kas iestatīta izslēgties pēc piecām minūtēm un aizmigt pēc trīsdesmit, sestajā minūtē rādīs tumšu ekrānu ar pilnīgi veselu tuneli. Kļūme trīsdesmitajā minūtē ir cits notikums ar citu risinājumu, un abi izskatās vienādi no istabas otras puses.
Otrā pārbaude: lieciet enerģijas un tīkla notikumus uz vienas laika ass
Lasiet žurnālu ierobežotam laika logam, nevis visai palaišanai, un iekļaujiet gan pieteikšanās pārvaldnieku, gan savienojuma īpašnieku:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list
Pirmā komanda rāda miega pieprasījumus, pamošanos un tīkla pārejas, kas tiem sekoja. Otrā rāda, kas pašlaik tur inhibējošo slēdzeni, kas jums pasaka, vai kaut kas apzināti bloķē miegu un kura programma tas ir. Pielāgojiet vienību nosaukumus, ja jūsu savienojuma īpašnieks nav NetworkManager, un atcerieties, ka cita lietotāja vienības vai sistēmas žurnāla lasīšana ir atkarīga no vietējās politikas.
Trūkstoša rinda nav negatīvs rezultāts. Ja izvēlētās vienības žurnāls jūsu kontam nav redzams, miega ieraksta neesamība neko nepierāda, un secinājums „tas nekad nav gulējis“ no tukša filtra ir ceļš, kā cilvēki pavada nedēļu, regulējot savienojuma uzturēšanas signālus.
Trešā pārbaude: ja tas aizmiga, izlemiet, vai tas bija apzināti
Tiklīdz miega pāreja parādās laika asī, jautājums mainās no „kāpēc VPN salūza“ uz „vai iekārtai vispār vajadzēja gulēt“. Klēpjdatorā atbilde bieži ir jā, un tuneļa pārtraukums ir gaidīta uzvedība, no kuras klientam jāatgūstas pamošanās brīdī. Darbstacijā, kurai jāpaliek sasniedzamai, maināma ir miega politika. Lai izlemtu, uz kuru no šīm divām iekārtām jūs skatāties, vajadzīgs viens jautājums, un tas nav jautājums, uz kuru žurnāls var atbildēt jūsu vietā.
Mainiet to ar vadīklām, kas pieder pieteiktajai sesijai, vai ar administratora atbalstītu mehānismu, ja prasība attiecas uz visu iekārtu. Displeja pārvaldnieka iestatījuma rediģēšana, esot pieteiktam ar citu kontu, nav tā pati darbība un izskatīsies tā, it kā tā būtu strādājusi, līdz sāksies nākamā sesija. Pilnīga enerģijas pārvaldības izslēgšana ir plaša pirmā reakcija, kas maksā akumulatora darbības laiku un slēpj īsto politikas jautājumu.
Ceturtā pārbaude: ja tas palika nomodā, skatiet tīklu un klientu
Nomodā esošai iekārtai, kas zaudēja tuneli, ir viens no trim stāstiem: piekļuves tīkls krita, VPN klients apstājās vai tika restartēts, vai servera puse ļāva asociācijai beigties, kamēr klients joprojām ticēja, ka ir savienots. Salīdziniet pamata saites notikuma laikspiedolus ar tuneļa notikumu un esiet precīzi par to, kurš notika pirmais.
Pēc tam pārbaudiet atjaunošanās ceļu atsevišķi no sākotnējās sesijas. Jauns pieprasījums caur atjaunoto tuneli var izdoties, kamēr ilglaicīgā lietotnes sesija, kas tika atvērta pirms pārtraukuma, paliek salauzta, jo lietotne tur novecojušu ligzdu vai kešatmiņā saglabātu adresi. Tā ir lietotnes problēma, nevis pierādījums tam, ka tunelis neatgriezās.
Ko satur noderīgs ziņojums
Pierakstiet secību ar laikspiedoliem un īpašniekiem: kad sesija tika bloķēta, kad ekrāns kļuva tumšs, vai tika reģistrēts miega pieprasījums, kad saite krita un atgriezās, kad tunelis mainīja stāvokli un ko lietotne faktiski darīja. Katram punktam ir īpašnieks, tāpēc katru punktu var nodot īstajam cilvēkam, nevis pārvērst to vispārīgā sūdzībā par Linux.
Ja kāda no šīm rindām trūkst, tas ir nākamais, kas jāmēra, nevis nākamais, kas jāmaina. Laika ass ar robu ir informatīvāka par iestatījumu maiņu, kas veikta pēc izjūtas.