VPN valt weg als het scherm donker wordt: vergrendeling, scherm uit of slaapstand?

Als iemand zegt dat de VPN stierf toen het scherm donker werd, is de eerste nuttige vraag welk van de drie gebeurtenissen echt plaatsvond: de sessie werd vergrendeld, het paneel werd uitgeschakeld, of de hele machine ging slapen. Dat zijn aparte mechanismen op aparte timers, en slechts één ervan kan verhinderen dat een proces überhaupt wordt ingepland. Doorloop de controles hieronder in volgorde. Stop bij de eerste die de vraag beantwoordt, want elke controle daarna beantwoordt iets anders.

Controle één: scheid de vergrendeling van het scherm uit en van de slaapstand

Een vergrendeling verandert wie de sessie mag gebruiken; de compositor blijft tekenen, de netwerkstack blijft draaien en de VPN-client merkt niets. Het doven van het scherm schakelt het paneel uit na een inactief interval en laat de machine volledig wakker. Slaapstand stopt de CPU's, wat betekent dat geen enkel proces in de gebruikersruimte wordt ingepland, dus geen enkele keepalive kan afgaan, hoe kort je het interval ook instelt.

Die tabel is de reden dat „het scherm werd donker“ geen diagnose is. Een desktop die na vijf minuten dooft en na dertig in slaapstand gaat, toont in de zesde minuut een donker scherm bij een volledig gezonde tunnel. De storing in de dertigste minuut is een andere gebeurtenis met een andere oplossing, en beide zien er vanaf de andere kant van de kamer hetzelfde uit.

Controle twee: zet energie- en netwerkgebeurtenissen op één tijdlijn

Lees het journaal voor een begrensd venster in plaats van de hele opstart, en neem zowel de aanmeldbeheerder als de eigenaar van de verbinding mee:

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

De eerste opdracht toont slaapverzoeken, het ontwaken en de netwerkoverschakelingen die daarop volgden. De tweede toont wat momenteel een inhibitorvergrendeling vasthoudt, wat je vertelt of iets de slaap bewust blokkeert en welk programma dat is. Pas de unitnamen aan als de eigenaar van je verbinding niet NetworkManager is, en onthoud dat het lezen van een unit van een andere gebruiker of het systeemjournaal van lokaal beleid afhangt.

Een ontbrekende regel is geen negatief resultaat. Als het journaal van de gekozen unit niet zichtbaar is voor jouw account, bewijst de afwezigheid van een slaapregistratie niets, en uit een leeg filter concluderen „hij heeft nooit geslapen“ is de manier waarop mensen een week lang keepalives bijstellen.

Controle drie: als hij in slaapstand ging, beslis of dat de bedoeling was

Zodra een slaapovergang op de tijdlijn staat, verandert de vraag van waarom de VPN brak naar of de machine überhaupt had moeten slapen. Op een laptop is het antwoord vaak ja, en de tunnelonderbreking is verwacht gedrag waarvan de client bij het ontwaken moet herstellen. Op een werkstation dat bereikbaar moet blijven, is het slaapbeleid het ding dat moet veranderen. Bepalen naar welke van die twee machines je kijkt kost één vraag, en het is geen vraag die het journaal voor je kan beantwoorden.

Verander het via de bedieningselementen die bij de aangemelde sessie horen, of via een door de beheerder ondersteund mechanisme als de eis voor de hele machine geldt. Een instelling van de weergavebeheerder bewerken terwijl je als een ander account bent aangemeld is niet dezelfde handeling en zal lijken te werken tot de volgende sessie begint. Energiebeheer volledig uitschakelen is een brede eerste reactie die batterijduur kost en de eigenlijke beleidsvraag verbergt.

Controle vier: als hij wakker bleef, kijk naar het netwerk en de client

Een wakker machine die zijn tunnel kwijtraakte, heeft een van drie verhalen: het toegangsnetwerk viel weg, de VPN-client stopte of herstartte, of de serverkant liet de associatie verlopen terwijl de client bleef geloven dat hij verbonden was. Vergelijk de tijdstempels van de onderliggende linkgebeurtenis met de tunnelgebeurtenis, en wees precies over welke eerst kwam.

Test daarna het herstelpad apart van de oorspronkelijke sessie. Een nieuw verzoek via de herstelde tunnel kan slagen terwijl de langdurige applicatiesessie die vóór de onderbreking werd geopend kapot blijft, omdat de applicatie een verouderde socket of een gecacht adres vasthoudt. Dat is een applicatieprobleem, geen bewijs dat de tunnel niet terugkwam.

Wat een nuttig rapport bevat

Schrijf de volgorde op met tijdstempels en eigenaren: wanneer de sessie werd vergrendeld, wanneer het scherm doofde, of een slaapverzoek werd geregistreerd, wanneer de link wegviel en terugkwam, wanneer de tunnel van status veranderde en wat de applicatie werkelijk deed. Elk item heeft een eigenaar, dus elk item kan naar de juiste persoon in plaats van een algemene klacht over Linux te worden.

Als een van die regels ontbreekt, is dat het volgende dat moet worden gemeten en niet het volgende dat moet worden veranderd. Een tijdlijn met een gat is informatiever dan een instellingswijziging op gevoel.