VPN:en faller när skärmen blir mörk: låsning, släckt skärm eller viloläge?

När någon säger att VPN:en dog när skärmen blev mörk, är den första användbara frågan vilken av tre händelser som faktiskt inträffade: sessionen låstes, panelen släcktes, eller hela maskinen gick i viloläge. Det är separata mekanismer på separata timers, och bara en av dem kan helt hindra en process från att schemaläggas. Gå igenom kontrollerna nedan i ordning. Stanna vid den första som svarar på frågan, eftersom varje kontroll efter den svarar på något annat.

Kontroll ett: skilj låsningen från släckningen och från viloläget

En låsning ändrar vem som får använda sessionen; kompositorn fortsätter att rita, nätverksstacken fortsätter att köra och VPN-klienten märker ingenting. Släckning av skärmen stänger av panelen efter ett inaktivt intervall och lämnar maskinen helt vaken. Viloläge stoppar processorerna, vilket betyder att ingen användarrymdsprocess schemaläggs, så ingen keepalive kan utlösas, hur kort du än ställer in intervallet.

Den tabellen är anledningen till att ”skärmen blev mörk” inte är en diagnos. En stationär dator inställd på att släckas efter fem minuter och gå i viloläge efter trettio visar en mörk skärm i den sjätte minuten med en helt frisk tunnel. Felet i den trettionde minuten är en annan händelse med en annan lösning, och båda ser likadana ut från andra sidan rummet.

Kontroll två: sätt ström- och nätverkshändelser på en enda tidslinje

Läs journalen för ett avgränsat fönster i stället för hela uppstarten, och ta med både inloggningshanteraren och ägaren av anslutningen:

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

Det första kommandot visar vilolägesförfrågningar, uppvaknandet och de nätverksövergångar som följde. Det andra visar vad som för närvarande håller ett inhibitorlås, vilket talar om för dig om något blockerar viloläget med avsikt och vilket program det är. Justera enhetsnamnen om ägaren av din anslutning inte är NetworkManager, och kom ihåg att läsning av en annan användares enhet eller systemjournalen beror på lokal policy.

En saknad rad är inte ett negativt resultat. Om journalen för den valda enheten inte är synlig för ditt konto bevisar frånvaron av en vilolägesregistrering ingenting, och slutsatsen ”den sov aldrig” från ett tomt filter är hur folk spenderar en vecka på att justera keepalive.

Kontroll tre: om den gick i viloläge, avgör om det var meningen

När en vilolägesövergång väl finns på tidslinjen ändras frågan från varför VPN:en gick sönder till om maskinen alls borde sova. På en bärbar dator är svaret ofta ja, och tunnelbrottet är förväntat beteende som klienten bör återhämta sig från vid uppvaknandet. På en arbetsstation som ska förbli nåbar är vilolägespolicyn det som måste ändras. Att avgöra vilken av dessa två maskiner du tittar på kräver en fråga, och det är inte en fråga som journalen kan svara på åt dig.

Ändra den via de kontroller som hör till den inloggade sessionen, eller via en administratörsstödd mekanism om kravet gäller hela maskinen. Att redigera en inställning i skärmhanteraren medan du är inloggad som ett annat konto är inte samma åtgärd och kommer att se ut som att den fungerade tills nästa session börjar. Att stänga av strömhanteringen helt är en bred första reaktion som kostar batteritid och döljer den egentliga policyfrågan.

Kontroll fyra: om den förblev vaken, titta på nätverket och klienten

En vaken maskin som förlorade sin tunnel har en av tre historier: åtkomstnätet föll, VPN-klienten stoppade eller startade om, eller serversidan lät associationen löpa ut medan klienten fortsatte att tro att den var ansluten. Jämför tidsstämplarna för den underliggande länkhändelsen med tunnelhändelsen, och var precis om vilken som kom först.

Testa sedan återställningsvägen separat från den ursprungliga sessionen. En ny begäran genom den återställda tunneln kan lyckas medan den långvariga applikationssessionen som öppnades före avbrottet förblir trasig, eftersom applikationen håller en föråldrad socket eller en cachad adress. Det är ett applikationsproblem, inte bevis för att tunneln inte kom tillbaka.

Vad en användbar rapport innehåller

Skriv ner förloppet med tidsstämplar och ägare: när sessionen låstes, när skärmen släcktes, om en vilolägesförfrågan registrerades, när länken föll och kom tillbaka, när tunneln bytte tillstånd och vad applikationen faktiskt gjorde. Varje post har en ägare, så varje post kan lämnas till rätt person i stället för att bli ett allmänt klagomål på Linux.

Om någon av dessa rader saknas är det nästa sak att mäta snarare än nästa sak att ändra. En tidslinje med ett hål är mer informativ än en inställningsändring gjord på en känsla.