VPN falder, når skærmen bliver mørk: lås, slukket skærm eller dvale?

Når nogen siger, at VPN'en døde, da skærmen blev mørk, er det første nyttige spørgsmål, hvilken af tre hændelser der faktisk skete: sessionen blev låst, panelet blev slukket, eller hele maskinen gik i dvale. Det er adskilte mekanismer på adskilte timere, og kun én af dem kan helt forhindre, at en proces bliver planlagt. Gå gennem kontrollerne nedenfor i rækkefølge. Stop ved den første, der besvarer spørgsmålet, fordi hver kontrol efter den besvarer noget andet.

Kontrol et: adskil låsen fra det slukkede skærmbillede og fra dvalen

En lås ændrer, hvem der må bruge sessionen; compositoren bliver ved med at tegne, netværksstakken kører videre, og VPN-klienten bemærker intet. Slukning af skærmbilledet slukker panelet efter et inaktivt interval og efterlader maskinen helt vågen. Dvale stopper CPU'erne, hvilket betyder, at ingen brugerrumsproces bliver planlagt, så ingen keepalive kan udløses, uanset hvor kort du sætter intervallet.

Den tabel er grunden til, at »skærmen blev mørk« ikke er en diagnose. En stationær computer sat til at slukke skærmen efter fem minutter og gå i dvale efter tredive vil vise en mørk skærm i det sjette minut med en fuldstændig sund tunnel. Fejlen i det tredivte minut er en anden hændelse med en anden løsning, og begge ser ens ud fra den anden side af lokalet.

Kontrol to: sæt strøm- og netværkshændelser på én tidslinje

Læs journalen for et afgrænset vindue i stedet for hele opstarten, og medtag både login-manageren og forbindelsens ejer:

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

Den første kommando viser dvaleforespørgsler, genoptagelse og de netværksskift, der fulgte dem. Den anden viser, hvad der i øjeblikket holder en inhibitorlås, hvilket fortæller dig, om noget bevidst blokerer dvale, og hvilket program det er. Justér enhedsnavnene, hvis ejeren af din forbindelse ikke er NetworkManager, og husk, at læsning af en anden brugers enhed eller systemjournalen afhænger af den lokale politik.

En manglende linje er ikke et negativt resultat. Hvis journalen for den valgte enhed ikke er synlig for din konto, beviser fraværet af en dvaleregistrering intet, og at konkludere »den sov aldrig« ud fra et tomt filter er måden, hvorpå folk bruger en uge på at justere keepalive.

Kontrol tre: hvis den gik i dvale, afgør om det var meningen

Når først en dvalovergang er på tidslinjen, ændres spørgsmålet fra, hvorfor VPN'en brød, til, om maskinen overhovedet burde sove. På en bærbar er svaret ofte ja, og tunnelafbrydelsen er forventet adfærd, som klienten bør komme sig over ved genoptagelse. På en arbejdsstation, der skal forblive tilgængelig, er det dvalepolitikken, der skal ændres. At afgøre, hvilken af de to maskiner du kigger på, kræver ét spørgsmål, og det er ikke et spørgsmål, journalen kan besvare for dig.

Ændr den via de kontroller, der hører til den loggede session, eller via en administratorunderstøttet mekanisme, hvis kravet gælder hele maskinen. At redigere en indstilling i display-manageren, mens du er logget ind som en anden konto, er ikke den samme handling og vil se ud som om den virkede, indtil den næste session starter. At slå strømstyring helt fra er en bred første reaktion, der koster batteritid og skjuler det egentlige politikspørgsmål.

Kontrol fire: hvis den forblev vågen, se på netværket og klienten

En vågen maskine, der mistede sin tunnel, har en af tre historier: adgangsnetværket faldt, VPN-klienten stoppede eller genstartede, eller serversiden lod associationen udløbe, mens klienten fortsat troede, at den var forbundet. Sammenlign tidsstemplerne for den underliggende linkhændelse med tunnelehændelsen, og vær præcis om, hvilken der kom først.

Test derefter gendannelsesvejen separat fra den oprindelige session. En ny anmodning gennem den gendannede tunnel kan lykkes, mens den langvarige programsession, der blev åbnet før afbrydelsen, forbliver brudt, fordi programmet holder en forældet socket eller en cachet adresse. Det er et programproblem, ikke bevis for, at tunnelen ikke kom tilbage.

Hvad en nyttig rapport indeholder

Skriv forløbet med tidsstempler og ejere: hvornår sessionen blev låst, hvornår skærmen blev slukket, om en dvaleforespørgsel blev registreret, hvornår forbindelsen faldt og kom tilbage, hvornår tunnelen skiftede tilstand, og hvad programmet faktisk gjorde. Hvert punkt har en ejer, så hvert punkt kan gives til den rigtige person i stedet for at blive en generel klage over Linux.

Hvis nogen af disse linjer mangler, er det den næste ting at måle snarere end den næste ting at ændre. En tidslinje med et hul er mere informativ end en indstillingsændring foretaget på en fornemmelse.