La VPN cau quan la pantalla s'apaga: bloqueig, esvaïment o suspensió?

Quan algú diu que la VPN va morir quan la pantalla es va apagar, la primera pregunta útil és quin dels tres esdeveniments va passar realment: la sessió es va bloquejar, el panell es va apagar o tota la màquina va entrar en repòs. Són mecanismes separats amb temporitzadors separats, i només un d'ells pot impedir del tot que un procés es planifiqui. Recorreu les comprovacions següents en ordre. Atureu-vos a la primera que respongui la pregunta, perquè cada comprovació posterior respon una altra cosa.

Primera comprovació: separeu el bloqueig de l'esvaïment i del repòs

El bloqueig canvia qui pot fer servir la sessió; el compositor continua dibuixant, la pila de xarxa continua funcionant i el client de la VPN no se n'adona. L'esvaïment de la pantalla apaga el panell després d'un interval d'inactivitat i deixa la màquina completament desperta. La suspensió atura les CPU, cosa que vol dir que cap procés d'espai d'usuari es planifica, així que cap senyal de manteniment no pot disparar-se per curt que sigui l'interval.

Aquesta taula és la raó per la qual «la pantalla s'ha apagat» no és un diagnòstic. Un escriptori configurat per esvair-se als cinc minuts i suspendre's als trenta mostrarà una pantalla fosca al minut sis amb un túnel perfectament sa. La fallada al minut trenta és un altre esdeveniment amb una altra solució, i tots dos es veuen iguals des de l'altra banda de l'habitació.

Segona comprovació: poseu els esdeveniments d'energia i xarxa en una sola línia temporal

Llegiu el registre d'una finestra limitada en lloc de tot l'arrencada, i incloeu tant el gestor d'inici de sessió com el propietari de la connexió:

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

La primera ordre mostra les peticions de repòs, la represa i les transicions de xarxa que les van seguir. La segona mostra què té actualment un bloqueig inhibidor, cosa que us diu si alguna cosa bloqueja el repòs deliberadament i quin programa és. Ajusteu els noms d'unitat si el propietari de la connexió no és NetworkManager, i recordeu que llegir la unitat d'un altre usuari o el registre del sistema depèn de la política local.

Una línia absent no és un resultat negatiu. Si el registre de la unitat seleccionada no és visible per al vostre compte, l'absència d'un registre de repòs no demostra res, i concloure «mai no ha dormit» a partir d'un filtre buit és com la gent acaba ajustant senyals de manteniment durant una setmana.

Tercera comprovació: si s'ha suspès, decidiu si era la intenció

Un cop una transició de repòs és a la línia temporal, la pregunta canvia de per què s'ha trencat la VPN a si la màquina hauria d'haver dormit. En un portàtil la resposta sovint és sí, i la caiguda del túnel és un comportament esperat del qual el client s'ha de recuperar en reprendre. En una estació de treball que ha de romandre accessible, la política de repòs és el que cal canviar. Decidir a quina d'aquestes dues màquines mireu demana una pregunta, i no és una pregunta que el registre pugui respondre per vosaltres.

Canvieu-ho amb els controls que pertanyen a la sessió iniciada, o amb un mecanisme admès per l'administrador si el requisit és per a tota la màquina. Editar un paràmetre del gestor de pantalla mentre teniu la sessió iniciada amb un altre compte no és la mateixa acció i semblarà que ha funcionat fins que comenci la sessió següent. Desactivar del tot la gestió d'energia és una primera reacció àmplia que costa vida de bateria i amaga la pregunta política real.

Quarta comprovació: si ha romàs desperta, mireu la xarxa i el client

Una màquina desperta que ha perdut el túnel té una de tres històries: la xarxa d'accés ha caigut, el client de la VPN s'ha aturat o s'ha reiniciat, o el costat del servidor ha fet expirar l'associació mentre el client continuava creient que estava connectat. Compareu les marques de temps de l'esdeveniment d'enllaç subjacent amb l'esdeveniment del túnel, i sigueu precisos sobre quin va arribar primer.

Després proveu el camí de recuperació per separat de la sessió original. Una petició nova a través del túnel recuperat pot tenir èxit mentre la sessió d'aplicació de llarga durada oberta abans de la caiguda continua trencada, perquè l'aplicació té un sòcol obsolet o una adreça a la memòria cau. Això és un problema de l'aplicació, no una prova que el túnel no hagi tornat.

Què conté un informe útil

Escriviu la seqüència amb marques de temps i propietaris: quan es va bloquejar la sessió, quan es va esvair la pantalla, si es va enregistrar una petició de repòs, quan l'enllaç va caure i va tornar, quan el túnel va canviar d'estat i què va fer realment l'aplicació. Cada element té un propietari, així que cada element es pot lliurar a la persona correcta en lloc de convertir-se en una queixa general sobre Linux.

Si falta qualsevol d'aquestes files, això és el següent que cal mesurar i no el següent que cal canviar. Una línia temporal amb un buit és més informativa que un canvi de paràmetres fet per intuïció.