VPN faller når skjermen blir mørk: lås, slukket skjerm eller dvale?

Når noen sier at VPN-en døde da skjermen ble mørk, er det første nyttige spørsmålet hvilken av tre hendelser som faktisk skjedde: økten ble låst, panelet ble slått av, eller hele maskinen gikk i dvale. Det er atskilte mekanismer på atskilte timere, og bare én av dem kan helt hindre en prosess i å bli planlagt. Gå gjennom kontrollene nedenfor i rekkefølge. Stopp ved den første som svarer på spørsmålet, fordi hver kontroll etter den svarer på noe annet.

Kontroll én: skill låsen fra slukket skjerm og fra dvale

En lås endrer hvem som har lov til å bruke økten; kompositoren fortsetter å tegne, nettverksstakken fortsetter å kjøre, og VPN-klienten merker ingenting. Slukking av skjermen slår av panelet etter et inaktivt intervall og lar maskinen være helt våken. Dvale stopper CPU-ene, noe som betyr at ingen brukerromsprosess blir planlagt, så ingen keepalive kan utløses, uansett hvor kort du setter intervallet.

Den tabellen er grunnen til at «skjermen ble mørk» ikke er en diagnose. En stasjonær maskin satt til å slukke skjermen etter fem minutter og gå i dvale etter tretti vil vise en mørk skjerm i det sjette minuttet med en fullstendig sunn tunnel. Feilen i det trettiende minuttet er en annen hendelse med en annen løsning, og begge ser like ut fra den andre siden av rommet.

Kontroll to: sett strøm- og nettverkshendelser på én tidslinje

Les journalen for et avgrenset vindu i stedet for hele oppstarten, og ta med både innloggingsbehandleren og eieren av tilkoblingen:

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

Den første kommandoen viser dvaleanmodninger, gjenopptakelse og nettverksovergangene som fulgte dem. Den andre viser hva som for øyeblikket holder en inhibitorlås, noe som forteller deg om noe blokkerer dvale med vilje og hvilket program det er. Juster enhetsnavnene hvis eieren av tilkoblingen din ikke er NetworkManager, og husk at lesing av en annen brukers enhet eller systemjournalen avhenger av lokal policy.

En manglende linje er ikke et negativt resultat. Hvis journalen for den valgte enheten ikke er synlig for kontoen din, beviser fraværet av en dvaleregistrering ingenting, og å konkludere «den sov aldri» fra et tomt filter er måten folk bruker en uke på å justere keepalive.

Kontroll tre: hvis den gikk i dvale, avgjør om det var meningen

Når en dvaleovergang først er på tidslinjen, endres spørsmålet fra hvorfor VPN-en brøt til om maskinen i det hele tatt burde sove. På en bærbar er svaret ofte ja, og tunnelbruddet er forventet atferd som klienten bør komme seg fra ved gjenopptakelse. På en arbeidsstasjon som skal forbli tilgjengelig, er dvalepolicyen det som må endres. Å avgjøre hvilken av disse to maskinene du ser på krever ett spørsmål, og det er ikke et spørsmål journalen kan svare på for deg.

Endre den via kontrollene som hører til den innloggede økten, eller via en administratorstøttet mekanisme hvis kravet gjelder hele maskinen. Å redigere en innstilling i skjermbehandleren mens du er logget inn som en annen konto er ikke den samme handlingen og vil se ut som den virket til neste økt starter. Å slå av strømstyringen helt er en bred første reaksjon som koster batteritid og skjuler det egentlige policyspørsmålet.

Kontroll fire: hvis den forble våken, se på nettverket og klienten

En våken maskin som mistet tunnelen sin har en av tre historier: aksessnettverket falt, VPN-klienten stoppet eller startet på nytt, eller serversiden lot assosiasjonen utløpe mens klienten fortsatte å tro at den var tilkoblet. Sammenlign tidsstemplene for den underliggende lenkehendelsen med tunnelhendelsen, og vær presis på hvilken som kom først.

Test deretter gjenopprettingsveien separat fra den opprinnelige økten. En ny forespørsel gjennom den gjenopprettede tunnelen kan lykkes mens den langvarige applikasjonsøkten som ble åpnet før bruddet forblir ødelagt, fordi applikasjonen holder en utdatert socket eller en bufret adresse. Det er et applikasjonsproblem, ikke bevis for at tunnelen ikke kom tilbake.

Hva en nyttig rapport inneholder

Skriv ned rekkefølgen med tidsstempler og eiere: når økten ble låst, når skjermen ble slukket, om en dvaleanmodning ble registrert, når lenken falt og kom tilbake, når tunnelen skiftet tilstand og hva applikasjonen faktisk gjorde. Hvert element har en eier, så hvert element kan gis til riktig person i stedet for å bli en generell klage på Linux.

Hvis noen av disse linjene mangler, er det den neste tingen å måle snarere enn den neste tingen å endre. En tidslinje med et hull er mer informativ enn en innstillingsendring gjort på en magefølelse.