VPN-ul cade când ecranul se întunecă: blocare, stingere sau suspendare?
O sesiune blocată, un ecran stins și o mașină suspendată sunt trei evenimente diferite. Corelați-le cu journalctl înainte de a da vina pe mecanismul de menținere a conexiunii VPN.
Când cineva spune că VPN-ul a murit când ecranul s-a întunecat, prima întrebare utilă este care dintre cele trei evenimente s-a produs de fapt: sesiunea s-a blocat, panoul s-a stins sau întreaga mașină a intrat în repaus. Acestea sunt mecanisme separate pe temporizatoare separate, și doar unul dintre ele poate împiedica complet planificarea unui proces. Parcurgeți verificările de mai jos în ordine. Opriți-vă la prima care răspunde la întrebare, pentru că fiecare verificare de după ea răspunde la altceva.
Prima verificare: separați blocarea de stingere și de repaus
Blocarea schimbă cine are voie să folosească sesiunea; compozitorul continuă să deseneze, stiva de rețea continuă să ruleze, iar clientul VPN nu observă nimic. Stingerea ecranului oprește panoul după un interval de inactivitate și lasă mașina complet trează. Repausul oprește procesoarele, ceea ce înseamnă că niciun proces din spațiul utilizator nu este planificat, așa că niciun semnal de menținere nu poate porni, oricât de scurt ați seta intervalul.
| 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 |
Acest tabel este motivul pentru care „ecranul s-a întunecat“ nu este un diagnostic. Un desktop setat să se stingă după cinci minute și să intre în repaus după treizeci va arăta un ecran întunecat în minutul șase cu un tunel perfect sănătos. Defecțiunea din minutul treizeci este un alt eveniment cu altă soluție, iar ambele arată la fel de la celălalt capăt al camerei.
A doua verificare: puneți evenimentele de alimentare și de rețea pe o singură linie temporală
Citiți jurnalul pentru o fereastră limitată, nu pentru întreaga pornire, și includeți atât managerul de autentificare, cât și proprietarul conexiunii:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --listPrima comandă arată cererile de repaus, trezirea și tranzițiile de rețea care au urmat. A doua arată ce deține în acest moment un blocaj inhibitor, ceea ce vă spune dacă ceva blochează intenționat repausul și care program este. Ajustați numele unităților dacă proprietarul conexiunii nu este NetworkManager și rețineți că citirea unității altui utilizator sau a jurnalului de sistem depinde de politica locală.
O linie lipsă nu este un rezultat negativ. Dacă jurnalul unității alese nu este vizibil pentru contul dumneavoastră, absența unei înregistrări de repaus nu dovedește nimic, iar concluzia „nu a dormit niciodată“ dintr-un filtru gol este felul în care oamenii ajung să regleze menținerea conexiunii o săptămână întreagă.
A treia verificare: dacă a intrat în repaus, decideți dacă a fost intenționat
Odată ce o tranziție de repaus apare pe linia temporală, întrebarea se schimbă de la de ce s-a rupt VPN-ul la dacă mașina ar fi trebuit să doarmă deloc. Pe un laptop răspunsul este adesea da, iar întreruperea tunelului este un comportament așteptat din care clientul trebuie să-și revină la trezire. Pe o stație de lucru care trebuie să rămână accesibilă, politica de repaus este lucrul care trebuie schimbat. A decide la care dintre aceste două mașini vă uitați cere o singură întrebare, și nu este o întrebare la care jurnalul poate răspunde în locul dumneavoastră.
Schimbați-o prin controalele care aparțin sesiunii autentificate sau printr-un mecanism susținut de administrator dacă cerința este pentru întreaga mașină. Editarea unei setări a managerului de afișare în timp ce sunteți autentificat cu alt cont nu este aceeași acțiune și va părea că a funcționat până la începutul sesiunii următoare. Dezactivarea completă a gestionării energiei este o primă reacție largă care costă autonomia și ascunde adevărata întrebare de politică.
A patra verificare: dacă a rămas trează, uitați-vă la rețea și la client
O mașină trează care și-a pierdut tunelul are una din trei povești: rețeaua de acces a căzut, clientul VPN s-a oprit sau a repornit, ori partea serverului a lăsat asocierea să expire în timp ce clientul continua să creadă că este conectat. Comparați marcajele de timp ale evenimentului de legătură subiacent cu evenimentul tunelului și fiți precis despre care a venit primul.
Apoi testați calea de recuperare separat de sesiunea originală. O cerere nouă prin tunelul refăcut poate reuși în timp ce sesiunea de aplicație de lungă durată deschisă înainte de întrerupere rămâne stricată, pentru că aplicația ține un socket învechit sau o adresă din cache. Aceasta este o problemă a aplicației, nu o dovadă că tunelul nu a revenit.
Ce conține un raport util
Scrieți secvența cu marcaje de timp și responsabili: când s-a blocat sesiunea, când s-a întunecat ecranul, dacă s-a înregistrat o cerere de repaus, când a căzut și a revenit legătura, când tunelul și-a schimbat starea și ce a făcut de fapt aplicația. Fiecare element are un responsabil, așa că fiecare element poate fi înmânat persoanei potrivite în loc să devină o plângere generală despre Linux.
Dacă lipsește vreuna dintre aceste linii, acesta este următorul lucru de măsurat, nu următorul lucru de schimbat. O linie temporală cu o lacună este mai informativă decât o modificare de setări făcută pe bănuială.