A VPN cae cando a pantalla se apaga: bloqueo, atenuación ou suspensión?
Unha sesión bloqueada, unha pantalla atenuada e un equipo suspendido son tres sucesos distintos. Correlaciónaos con journalctl antes de culpar o keepalive da VPN.
Cando alguén di que a VPN morreu cando a pantalla se escureceu, a primeira pregunta útil é cal dos tres sucesos ocorreu en realidade: bloqueouse a sesión, apagouse o panel ou todo o equipo entrou en repouso. Son mecanismos separados con temporizadores separados, e só un deles pode impedir por completo que un proceso se planifique. Percorra as comprobacións seguintes en orde. Detéñase na primeira que responda á pregunta, porque cada comprobación posterior responde a outra cousa.
Primeira comprobación: separe o bloqueo da atenuación e do repouso
O bloqueo cambia quen pode usar a sesión; o compositor segue debuxando, a pila de rede segue funcionando e o cliente da VPN non se decata. A atenuación da pantalla apaga o panel tras un intervalo de inactividade e deixa o equipo completamente esperto. A suspensión detén as CPU, o que significa que ningún proceso de espazo de usuario se planifica, así que ningún keepalive pode dispararse por curto que sexa o intervalo.
| Event | What it stops | Can it kill the tunnel? |
|---|---|---|
| Session lock | Input to your session | No |
| Display blank | The panel | No |
| Suspend to RAM | CPU scheduling, hence every process | Yes, and silently |
| Hibernate | Everything, with state written to disk | Yes |
Esa táboa é a razón de que «a pantalla escureceuse» non sexa un diagnóstico. Un escritorio configurado para atenuarse aos cinco minutos e suspenderse aos trinta mostrará unha pantalla escura no minuto seis cun túnel perfectamente san. O fallo no minuto trinta é outro suceso con outra solución, e ambos se ven iguais desde o outro lado da habitación.
Segunda comprobación: poña os sucesos de enerxía e rede nunha soa liña temporal
Lea o rexistro dunha xanela acoutada en lugar de todo o arranque, e inclúa tanto o xestor de inicio de sesión como o propietario da conexión:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --listO primeiro comando mostra as peticións de repouso, a reanudación e as transicións de rede que as seguiron. O segundo mostra que mantén actualmente un bloqueo inhibidor, o que lle di se algo bloquea o repouso a propósito e que programa é. Axuste os nomes de unidade se o propietario da súa conexión non é NetworkManager, e lembre que ler a unidade doutro usuario ou o rexistro do sistema depende da política local.
Unha liña ausente non é un resultado negativo. Se o rexistro da unidade seleccionada non é visible para a súa conta, a ausencia dun rexistro de repouso non demostra nada, e concluír «nunca durmiu» a partir dun filtro baleiro é como a xente acaba axustando keepalives durante unha semana.
Terceira comprobación: se se suspendeu, decida se era o previsto
Unha vez que unha transición de repouso está na liña temporal, a pregunta cambia de por que se rompeu a VPN a se o equipo debería ter durmido. Nun portátil a resposta adoita ser si, e o corte do túnel é un comportamento esperado do que o cliente debe recuperarse ao reanudar. Nunha estación de traballo que debe seguir sendo accesible, a política de repouso é o que hai que cambiar. Decidir a cal deses dous equipos está mirando require unha pregunta, e non é unha pregunta que o rexistro poida responder por vostede.
Cámbieo mediante os controis que pertencen á sesión iniciada, ou mediante un mecanismo avalado polo administrador se o requisito é para todo o equipo. Editar un axuste do xestor de pantalla mentres ten a sesión iniciada con outra conta non é a mesma acción e parecerá que funcionou ata que comece a sesión seguinte. Desactivar por completo a xestión de enerxía é unha primeira reacción ampla que custa vida de batería e oculta a verdadeira pregunta de política.
Cuarta comprobación: se seguiu esperto, mire a rede e o cliente
Un equipo esperto que perdeu o seu túnel ten unha de tres historias: caeu a rede de acceso, o cliente da VPN detívose ou reiniciouse, ou o lado do servidor deixou expirar a asociación mentres o cliente seguía crendo que estaba conectado. Compare as marcas de tempo do suceso de enlace subxacente co suceso do túnel, e sexa preciso sobre cal chegou primeiro.
Logo probe a ruta de recuperación por separado da sesión orixinal. Unha petición nova a través do túnel recuperado pode ter éxito mentres a sesión de aplicación de longa duración aberta antes do corte segue rota, porque a aplicación mantén un socket obsoleto ou un enderezo na caché. Iso é un problema da aplicación, non unha proba de que o túnel non volvese.
Que contén un informe útil
Escriba a secuencia con marcas de tempo e propietarios: cando se bloqueou a sesión, cando se atenuou a pantalla, se se rexistrou unha petición de repouso, cando caeu e volveu o enlace, cando cambiou de estado o túnel e que fixo realmente a aplicación. Cada elemento ten un propietario, así que cada elemento pode entregarse á persoa correcta en lugar de converterse nunha queixa xeral sobre Linux.
Se falta calquera desas filas, iso é o seguinte que hai que medir e non o seguinte que hai que cambiar. Unha liña temporal cun oco é máis informativa que un cambio de axustes feito por intuición.