VPN bie kur ekrani errësohet: bllokim, shuarje apo gjumë?

Kur dikush thotë se VPN vdiq kur ekrani u errësua, pyetja e parë e dobishme është cila nga tre ngjarjet ndodhi në të vërtetë: sesioni u bllokua, paneli u fik, apo e gjithë makina shkoi në gjumë. Këto janë mekanizma të veçantë në kohëmatës të veçantë, dhe vetëm njëri prej tyre mund të pengojë plotësisht planifikimin e një procesi. Kaloni nëpër kontrollet më poshtë sipas radhës. Ndaloni te i pari që i përgjigjet pyetjes, sepse çdo kontroll pas tij i përgjigjet diçkaje tjetër.

Kontrolli i parë: ndani bllokimin nga shuarja dhe nga gjumi

Bllokimi ndryshon kush lejohet të përdorë sesionin; kompozitori vazhdon të vizatojë, stivi i rrjetit vazhdon të punojë dhe klienti i VPN nuk vëren asgjë. Shuarja e ekranit e fik panelin pas një intervali pasiviteti dhe e lë makinën plotësisht zgjuar. Gjumi i ndalon procesorët, që do të thotë se asnjë proces në hapësirën e përdoruesit nuk planifikohet, prandaj asnjë sinjal i mbajtjes së lidhjes nuk mund të nisë, sado i shkurtër të jetë intervali që vendosni.

Pikërisht kjo tabelë është arsyeja pse «ekrani u errësua» nuk është diagnozë. Një kompjuter tavoline i vendosur të shuhet pas pesë minutash dhe të flejë pas tridhjetë do të tregojë një ekran të errët në minutën e gjashtë me një tunel plotësisht të shëndetshëm. Dështimi në minutën e tridhjetë është një ngjarje tjetër me një zgjidhje tjetër, dhe të dyja duken njësoj nga ana tjetër e dhomës.

Kontrolli i dytë: vendosni ngjarjet e energjisë dhe të rrjetit në një vijë të vetme kohore

Lexoni regjistrin për një dritare të kufizuar dhe jo për të gjithë nisjen, dhe përfshini si menaxherin e hyrjes ashtu edhe pronarin e lidhjes:

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

Komanda e parë tregon kërkesat për gjumë, zgjimin dhe kalimet e rrjetit që pasuan. E dyta tregon çfarë mban aktualisht një bllokim frenues, që ju tregon nëse diçka po bllokon qëllimisht gjumin dhe cili program është. Rregulloni emrat e njësive nëse pronari i lidhjes tuaj nuk është NetworkManager, dhe mbani mend se leximi i njësisë së një përdoruesi tjetër ose i regjistrit të sistemit varet nga politika lokale.

Një rresht që mungon nuk është rezultat negativ. Nëse regjistri i njësisë së zgjedhur nuk është i dukshëm për llogarinë tuaj, mungesa e një regjistrimi gjumi nuk provon asgjë, dhe përfundimi «nuk fjeti kurrë» nga një filtër bosh është mënyra se si njerëzit kalojnë një javë duke rregulluar mbajtjen e lidhjes.

Kontrolli i tretë: nëse shkoi në gjumë, vendosni nëse ishte e qëllimshme

Sapo një kalim në gjumë shfaqet në vijën kohore, pyetja ndryshon nga pse u prish VPN në a duhej të flinte makina fare. Në një laptop përgjigjja është shpesh po, dhe ndërprerja e tunelit është sjellje e pritur nga e cila klienti duhet të rikuperohet kur zgjohet. Në një stacion pune që duhet të mbetet i arritshëm, politika e gjumit është ajo që duhet ndryshuar. Të vendosësh se cila nga këto dy makina po shikon kërkon një pyetje, dhe nuk është një pyetje të cilës regjistri mund t'i përgjigjet në vendin tuaj.

Ndryshojeni përmes kontrolleve që i përkasin sesionit të hyrë, ose përmes një mekanizmi të mbështetur nga administratori nëse kërkesa është për të gjithë makinën. Redaktimi i një cilësimi të menaxherit të ekranit ndërsa jeni i hyrë me një llogari tjetër nuk është i njëjti veprim dhe do të duket se funksionoi derisa të nisë sesioni tjetër. Çaktivizimi i plotë i menaxhimit të energjisë është një reagim i parë i gjerë që kushton jetëgjatësinë e baterisë dhe fsheh pyetjen e vërtetë të politikës.

Kontrolli i katërt: nëse qëndroi zgjuar, shikoni rrjetin dhe klientin

Një makinë zgjuar që humbi tunelin e saj ka një nga tre historitë: rrjeti i aksesit ra, klienti i VPN u ndal ose u rinis, ose ana e serverit e la lidhjen të skadojë ndërsa klienti vazhdonte të besonte se ishte i lidhur. Krahasoni vulat kohore të ngjarjes së lidhjes bazë me ngjarjen e tunelit, dhe jini të saktë se cila erdhi e para.

Pastaj provoni rrugën e rikuperimit veçmas nga sesioni origjinal. Një kërkesë e re përmes tunelit të rikuperuar mund të ketë sukses ndërsa sesioni i aplikacionit afatgjatë i hapur përpara ndërprerjes mbetet i prishur, sepse aplikacioni mban një socket të vjetruar ose një adresë në cache. Ky është problem i aplikacionit, jo provë se tuneli nuk u kthye.

Çfarë përmban një raport i dobishëm

Shkruani sekuencën me vulat kohore dhe pronarët: kur u bllokua sesioni, kur u errësua ekrani, nëse u regjistrua një kërkesë për gjumë, kur ra lidhja dhe u kthye, kur tuneli ndryshoi gjendje dhe çfarë bëri në të vërtetë aplikacioni. Çdo artikull ka një pronar, prandaj çdo artikull mund t'i dorëzohet personit të duhur në vend që të bëhet ankesë e përgjithshme për Linux.

Nëse mungon ndonjë nga këto rreshta, kjo është gjëja tjetër që duhet matur dhe jo gjëja tjetër që duhet ndryshuar. Një vijë kohore me një boshllëk është më informuese se një ndryshim cilësimesh i bërë me hamendje.