journalctl para os registos de VPN: que unidade detém a ligação?

Comece pela unidade do systemd que realmente detém a ligação VPN, e não pelo comando de registo de que se lembra. Um serviço OpenVPN direto, uma unidade wg-quick e um perfil NetworkManager colocam as suas mensagens úteis em unidades diferentes, e uma consulta contra a unidade errada produz um resultado vazio que parece silêncio. Compare os três proprietários comuns, restrinja a janela e depois leia as etapas por ordem.

Compare os três proprietários comuns

Um serviço cliente do OpenVPN é normalmente uma unidade de instância com o nome do perfil, como [email protected]. As suas mensagens incluem o caminho da configuração, a análise das opções, o aperto de mão TLS e a instalação de rotas feita pelo cliente.

Uma unidade wg-quick é mais silenciosa por conceção. A configuração da interface ocorre no arranque, o aperto de mão é tratado pelo kernel e as renovações rotineiras de chaves não são registadas por predefinição, pelo que wg show é muitas vezes mais informativo do que o registo. Essa diferença importa quando compara um protocolo que regista a negociação com outro que não o faz.

O NetworkManager detém os perfis que criou, e as suas mensagens vivem sob NetworkManager.service mesmo quando o plugin subjacente é um assistente de VPN. Consulte tanto o gestor como a unidade assistente quando o perfil é gerido dessa forma.

Restrinja a consulta a uma unidade e uma janela

Consulte a unidade que identificou e limite o tempo à tentativa que está a investigar. Um dia costuma bastar, e uma janela mais curta é melhor quando a máquina se volta a ligar com frequência.

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

Verifique o nome instalado antes de confiar na consulta. O empacotamento da distribuição renomeia unidades, e um perfil que existe como ficheiro pode nunca ter sido ativado como serviço. Se a unidade não existir, o registo vazio fala-lhe da implementação e não do túnel.

Leia a primeira etapa falhada

Leia os eventos pela ordem em que ocorrem: procura do ponto final, transporte, identidade, autenticação, instalação de rotas e a falha posterior da aplicação. A primeira falha concreta é a que vale a pena investigar, porque tudo o que vem depois é consequência.

Um serviço que arranca com sucesso não prova que todos os recursos necessários estejam acessíveis. Um ciclo de reconexão pode produzir várias negociações separadas, por isso guarde o nome do perfil e a hora da tentativa junto aos eventos, e leia uma tentativa em vez de um fluxo fundido. Uma tentativa isolada é uma sequência com uma causa, enquanto um fluxo fundido é uma parede de linhas repetidas. Escreva o primeiro erro no ticket antes de continuar a ler.

Não misture um serviço falhado com um cliente manual

Se iniciou um cliente à mão depois de o serviço falhar, a sua saída vai para outro lugar e o comportamento pode ser diferente. Capture o novo resultado do mesmo proprietário e do mesmo pedido após uma correção suportada, para que a comparação mostre o que mudou em vez de misturar dois programas diferentes.

Não altere as marcas de tempo originais para as alinhar com outro anfitrião. Registe a zona horária e qualquer diferença de relógio conhecida em separado, porque uma cronologia que editou já não é prova.

Partilhe um extrato, não uma exportação

As entradas do registo podem conter nomes de utilizador, endereços de pontos finais, topologia privada e informação sobre o ambiente de scripts. Reveja o extrato real e oculte o que é sensível em vez de publicar uma exportação completa sem restrições. Cite as linhas que demonstram a falha e resuma o resto. Um extrato curto e revisto é mais fácil de usar do que um ficheiro que ninguém lê.

Envie a janela estreita, o nome da unidade e a primeira etapa falhada, e diga o que já descartou. O manual do systemd journalctl documenta os seletores e as opções de saída se precisar de um formato que a versão da distribuição suporte.