Kui keegi ütleb, et VPN suri siis, kui ekraan pimenes, on esimene kasulik küsimus, milline kolmest sündmusest tegelikult juhtus: sessioon lukustus, paneel lülitus välja või kogu masin läks unne. Need on eraldi mehhanismid eraldi taimeritel ja ainult üks neist saab üldse takistada protsessi ajastamist. Käige allolevad kontrollid järjekorras läbi. Peatuge esimesel, mis küsimusele vastab, sest iga järgnev kontroll vastab millelegi muule.

Esimene kontroll: eraldage lukustus pimenemisest ja uinumisest

Lukustus muudab, kellel on lubatud sessiooni kasutada; komposiitor jätkab joonistamist, võrgupinu jätkab tööd ja VPN-klient ei märka midagi. Ekraani tühjenemine lülitab paneeli pärast tegevusetuse intervalli välja ja jätab masina täiesti ärkvel. Uinumine peatab protsessorid, mis tähendab, et ühtki kasutajaruumi protsessi ei ajastata, seega ei saa ükski ühenduse hoidmise signaal käivituda, ükskõik kui lühikese intervalli te määrate.

EventWhat it stopsCan it kill the tunnel?
Session lockInput to your sessionNo
Display blankThe panelNo
Suspend to RAMCPU scheduling, hence every processYes, and silently
HibernateEverything, with state written to diskYes

Just selle tabeli tõttu ei ole «ekraan pimenes» diagnoos. Lauaarvuti, mis on seatud pimenema viie minuti ja uinuma kolmekümne minuti järel, näitab kuuendal minutil pimedat ekraani täiesti terve tunneliga. Tõrge kolmekümnendal minutil on teine sündmus teise lahendusega ja mõlemad näevad ruumi teisest otsast ühesugused välja.

Teine kontroll: pange toite- ja võrgusündmused ühele ajateljele

Lugege logi piiratud ajavahemiku kohta, mitte kogu alglaadimise kohta, ja kaasake nii sisselogimishaldur kui ka ühenduse omanik:

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

Esimene käsk näitab une taotlusi, ärkamist ja neile järgnenud võrguüleminekuid. Teine näitab, mis parasjagu hoiab inhibiitori lukku, mis ütleb teile, kas miski blokeerib une tahtlikult ja milline programm see on. Kohandage üksuste nimesid, kui teie ühenduse omanik ei ole NetworkManager, ja pidage meeles, et teise kasutaja üksuse või süsteemilogi lugemine sõltub kohalikust poliitikast.

Puuduv rida ei ole eitav tulemus. Kui valitud üksuse logi ei ole teie kontole nähtav, ei tõesta une kirje puudumine midagi, ja järeldus «see ei uinunud kunagi» tühjast filtrist on viis, kuidas inimesed veedavad nädala ühenduse hoidmise signaale häälestades.

Kolmas kontroll: kui see uinus, otsustage, kas see oli kavatsetud

Kui uneüleminek on ajateljel, muutub küsimus sellest, miks VPN katki läks, selleks, kas masin oleks üldse pidanud magama. Sülearvutis on vastus sageli jah ja tunneli katkestus on oodatud käitumine, millest klient peaks ärgates taastuma. Tööjaamas, mis peaks jääma kättesaadavaks, tuleb muuta unepoliitikat. Otsustamine, millist neist kahest masinast te vaatate, nõuab ühte küsimust ja see ei ole küsimus, millele logi teie eest vastata saab.

Muutke seda juhtelementide kaudu, mis kuuluvad sisselogitud sessioonile, või administraatori toetatud mehhanismi kaudu, kui nõue kehtib kogu masinale. Kuvarhalduri seade muutmine, kui olete sisse logitud teise kontoga, ei ole sama tegevus ja näib toimivat kuni järgmise sessiooni alguseni. Toitehalduse täielik väljalülitamine on lai esimene reaktsioon, mis maksab akukestvuse arvelt ja varjab tegeliku poliitikaküsimuse.

Neljas kontroll: kui see jäi ärkvele, vaadake võrku ja klienti

Ärkvel masinal, mis kaotas oma tunneli, on üks kolmest loost: juurdepääsuvõrk langes, VPN-klient peatus või taaskäivitus, või serveripool lasi seostuse aeguda, samal ajal kui klient jätkas uskumist, et on ühendatud. Võrrelge aluseks oleva lingisündmuse ajatempleid tunneli sündmuse omadega ja olge täpne selles, kumb tuli esimesena.

Seejärel testige taastumisteed algse sessioonist eraldi. Uus taotlus taastatud tunneli kaudu võib õnnestuda, samal ajal kui enne katkestust avatud pikaajaline rakenduse sessioon jääb katki, sest rakendus hoiab aegunud pesa või vahemällu salvestatud aadressi. See on rakenduse probleem, mitte tõestus, et tunnel ei tulnud tagasi.

Mida sisaldab kasulik aruanne

Kirjutage järjestus ajatemplite ja omanikega: millal sessioon lukustus, millal ekraan pimenes, kas une taotlus registreeriti, millal link langes ja tagasi tuli, millal tunnel olekut muutis ja mida rakendus tegelikult tegi. Igal real on omanik, seega saab iga rea anda õigele inimesele, selle asemel et sellest saaks üldine kaebus Linuxi kohta.

Kui mõni neist ridadest puudub, on see järgmine asi, mida mõõta, mitte järgmine asi, mida muuta. Lüngaga ajatelg on informatiivsem kui oletuse põhjal tehtud seadete muudatus.

Seotud artiklid