VPN fell når skjermen blir mørk: lås, sløkt skjerm eller dvale?
Ei låst økt, ein sløkt skjerm og ein maskin i dvale er tre ulike hendingar. Korreler dei med journalctl før du klandrar keepalive-mekanismen til VPN-en.
Når nokon seier at VPN-en døydde då skjermen vart mørk, er det første nyttige spørsmålet kva av tre hendingar som faktisk skjedde: økta vart låst, panelet vart sløkt, eller heile maskinen gjekk i dvale. Det er skilde mekanismar på skilde timar, og berre éin av dei kan heilt hindre ein prosess i å bli planlagd. Gå gjennom kontrollane nedanfor i rekkjefølgje. Stopp ved den første som svarar på spørsmålet, fordi kvar kontroll etter den svarar på noko anna.
Kontroll éin: skil låsen frå sløkt skjerm og frå dvale
Ein lås endrar kven som har lov til å bruke økta; kompositøren held fram med å teikne, nettverksstakken held fram med å køyre, og VPN-klienten merkar ingenting. Sløkking av skjermen slår av panelet etter eit inaktivt intervall og lèt maskinen vere heilt vaken. Dvale stoppar CPU-ane, noko som betyr at ingen brukarromsprosess blir planlagd, så ingen keepalive kan utløysast, uansett kor kort du set intervallet.
| 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 |
Den tabellen er grunnen til at «skjermen vart mørk» ikkje er ein diagnose. Ein stasjonær maskin sett til å sløkkje skjermen etter fem minutt og gå i dvale etter tretti vil vise ein mørk skjerm i det sjette minuttet med ein fullstendig sunn tunnel. Feilen i det trettiande minuttet er ei anna hending med ei anna løysing, og begge ser like ut frå den andre sida av rommet.
Kontroll to: set straum- og nettverkshendingar på éi tidsline
Les journalen for eit avgrensa vindauge i staden for heile oppstarten, og ta med både innloggingshandsamaren og eigaren av tilkoplinga:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list
Den første kommandoen viser dvaleønske, gjenopptaking og nettverksovergangane som følgde dei. Den andre viser kva som for augneblinken held ein inhibitorlås, noko som fortel deg om noko blokkerer dvale med vilje og kva program det er. Juster einingdsnamna om eigaren av tilkoplinga di ikkje er NetworkManager, og hugs at lesing av eininga til ein annan brukar eller systemjournalen avheng av lokal policy.
Ei manglande line er ikkje eit negativt resultat. Om journalen for den valde eininga ikkje er synleg for kontoen din, beviser fråværet av ein dvaleregistrering ingenting, og å konkludere «han sov aldri» frå eit tomt filter er måten folk brukar ei veke på å justere keepalive.
Kontroll tre: om han gjekk i dvale, avgjer om det var meininga
Når ein dvaleovergang først er på tidslina, endrar spørsmålet seg frå kvifor VPN-en braut til om maskinen i det heile burde sove. På ein berbar er svaret ofte ja, og tunnelbrotet er forventa åtferd som klienten bør kome seg frå ved gjenopptaking. På ein arbeidsstasjon som skal halde fram med å vere tilgjengeleg, er dvalepolicyen det som må endrast. Å avgjere kva av desse to maskinene du ser på krev eitt spørsmål, og det er ikkje eit spørsmål journalen kan svare på for deg.
Endre han via kontrollane som høyrer til den innlogga økta, eller via ein administratorstøtta mekanisme om kravet gjeld heile maskinen. Å redigere ei innstilling i skjermhandsamaren medan du er innlogga som ein annan konto er ikkje den same handlinga og vil sjå ut som han verka til neste økt startar. Å slå av straumstyringa heilt er ein brei første reaksjon som kostar batteritid og skjuler det eigentlege policyspørsmålet.
Kontroll fire: om han vart verande vaken, sjå på nettverket og klienten
Ein vaken maskin som mista tunnelen sin har éin av tre historier: aksessnettverket fall, VPN-klienten stoppa eller starta på nytt, eller serversida lét assosiasjonen gå ut medan klienten heldt fram med å tru at han var tilkopla. Samanlikn tidsstempla for den underliggjande lenkjehendinga med tunnelhendinga, og ver presis på kva som kom først.
Test deretter gjenopprettingsvegen skilt frå den opphavlege økta. Ein ny førespurnad gjennom den gjenoppretta tunnelen kan lukkast medan den langvarige applikasjonsøkta som vart opna før brotet blir verande øydelagd, fordi applikasjonen held ein utdatert socket eller ei bufra adresse. Det er eit applikasjonsproblem, ikkje bevis for at tunnelen ikkje kom tilbake.
Kva ein nyttig rapport inneheld
Skriv ned rekkjefølgja med tidsstempel og eigarar: når økta vart låst, når skjermen vart sløkt, om eit dvaleønske vart registrert, når lenkja fall og kom tilbake, når tunnelen skifta tilstand og kva applikasjonen faktisk gjorde. Kvart element har ein eigar, så kvart element kan givast til rett person i staden for å bli ei generell klage på Linux.
Om nokon av desse linjene manglar, er det den neste tingen å måle snarare enn den neste tingen å endre. Ei tidsline med eit hol er meir informativ enn ei innstillingsendring gjord på ein magekjensle.