A VPN cai quando o ecrã escurece: bloqueio, ecrã apagado ou suspensão?

Quando alguém diz que a VPN morreu quando o ecrã escureceu, a primeira pergunta útil é qual dos três eventos aconteceu realmente: a sessão ficou bloqueada, o painel foi desligado ou a máquina inteira entrou em suspensão. São mecanismos separados em temporizadores separados, e só um deles pode impedir por completo que um processo seja escalonado. Percorra as verificações abaixo pela ordem. Pare na primeira que responder à pergunta, porque cada verificação seguinte responde a outra coisa.

Primeira verificação: separe o bloqueio do escurecimento e da suspensão

O bloqueio altera quem pode usar a sessão; o compositor continua a desenhar, a pilha de rede continua a funcionar e o cliente da VPN não dá por nada. O escurecimento do ecrã desliga o painel após um intervalo de inatividade e deixa a máquina completamente acordada. A suspensão para as CPU, o que significa que nenhum processo em espaço de utilizador é escalonado, pelo que nenhum keepalive pode disparar, por mais curto que seja o intervalo.

É essa tabela a razão pela qual «o ecrã escureceu» não é um diagnóstico. Um computador de secretária configurado para escurecer aos cinco minutos e suspender aos trinta mostrará um ecrã escuro no minuto seis com um túnel perfeitamente saudável. A falha no minuto trinta é outro evento com outra solução, e ambos parecem iguais do outro lado da sala.

Segunda verificação: coloque os eventos de energia e de rede numa única linha temporal

Leia o registo para uma janela limitada em vez de todo o arranque, e inclua tanto o gestor de início de sessão como o proprietário da ligação:

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

O primeiro comando mostra pedidos de suspensão, o retomar e as transições de rede que se lhes seguiram. O segundo mostra o que detém atualmente um bloqueio inibidor, o que lhe diz se algo está a bloquear a suspensão de propósito e que programa é. Ajuste os nomes das unidades se o proprietário da sua ligação não for o NetworkManager, e lembre-se de que ler a unidade de outro utilizador ou o registo do sistema depende da política local.

Uma linha ausente não é um resultado negativo. Se o registo da unidade escolhida não for visível para a sua conta, a ausência de um registo de suspensão não prova nada, e concluir «nunca dormiu» a partir de um filtro vazio é como as pessoas acabam a ajustar keepalives durante uma semana.

Terceira verificação: se suspendeu, decida se era a intenção

Assim que uma transição de suspensão está na linha temporal, a pergunta muda de porque é que a VPN partiu para se a máquina devia ter dormido de todo. Num portátil a resposta é muitas vezes sim, e o corte do túnel é um comportamento esperado do qual o cliente deve recuperar ao retomar. Numa estação de trabalho que deve permanecer acessível, a política de suspensão é o que há a mudar. Decidir a qual dessas duas máquinas está a olhar exige uma pergunta, e não é uma pergunta a que o registo possa responder por si.

Altere-a através dos controlos que pertencem à sessão iniciada, ou através de um mecanismo suportado pelo administrador se o requisito for para toda a máquina. Editar uma definição do gestor de ecrã enquanto está com sessão iniciada noutra conta não é a mesma ação e parecerá ter funcionado até a sessão seguinte começar. Desativar por completo a gestão de energia é uma primeira reação ampla que custa autonomia e esconde a verdadeira questão de política.

Quarta verificação: se ficou acordada, olhe para a rede e para o cliente

Uma máquina acordada que perdeu o túnel tem uma de três histórias: a rede de acesso caiu, o cliente da VPN parou ou reiniciou, ou o lado do servidor deixou a associação expirar enquanto o cliente continuava a acreditar que estava ligado. Compare as marcas temporais do evento de ligação subjacente com o evento do túnel, e seja preciso sobre qual veio primeiro.

Depois teste o caminho de recuperação separadamente da sessão original. Um novo pedido através do túnel recuperado pode ter êxito enquanto a sessão de aplicação de longa duração aberta antes do corte continua quebrada, porque a aplicação mantém um socket obsoleto ou um endereço em cache. Isso é um problema da aplicação, não prova de que o túnel não voltou.

O que contém um relatório útil

Escreva a sequência com marcas temporais e responsáveis: quando a sessão ficou bloqueada, quando o ecrã escureceu, se foi registado um pedido de suspensão, quando a ligação caiu e voltou, quando o túnel mudou de estado e o que a aplicação fez realmente. Cada item tem um responsável, por isso cada item pode ser entregue à pessoa certa em vez de se tornar uma queixa geral sobre Linux.

Se faltar alguma dessas linhas, é a próxima coisa a medir e não a próxima coisa a mudar. Uma linha temporal com um buraco é mais informativa do que uma alteração de definições feita por intuição.