O que os registos locais do sistema revelam sobre uma ligação VPN

Cada computador mantém o seu próprio registo do que uma VPN fez, e a exportação da aplicação é normalmente a menos completa de todas. Os gestores de serviços anotam quando uma unidade arrancou, o kernel anota quando surgiu uma interface e a pilha de rede anota quando não foi possível aplicar rotas. Nenhum destes mecanismos sabe o que o cliente pretendia, e o cliente não sabe o que o kernel fez com o seu pedido.

Ler um destes registos isoladamente convida à conclusão errada. Leia dois, do mesmo minuto, e a sequência torna-se visível.

Três mecanismos com três vocabulários

No Linux, o diário do systemd captura mensagens do ciclo de vida da unidade a partir de wg-quick@wg0 ou do plugin VPN do NetworkManager, e o buffer circular do kernel transporta mensagens de interface e de encaminhamento. No Windows, o registo de eventos reparte a história pelos fornecedores de sistema, WLAN e acesso remoto, cada um com os seus próprios identificadores. No macOS, o registo unificado transporta mensagens limitadas ao subsistema que a Console gráfica só expõe em parte.

Os vocabulários não se traduzem. Um identificador de evento de uma plataforma não significa nada noutra, e uma captura de ecrã de uma caixa de diálogo do Windows não prova nada sobre uma unidade Linux.

O que os três partilham é um carimbo temporal, uma fonte e uma gravidade, e é esse trio que torna possível a correlação entre um registo do cliente e um registo do sistema operativo. A disponibilidade também varia: um contentor sem diário, uma imagem do Windows reduzida ou um nível de registo diminuído na compilação podem esconder uma camada inteira.

O que uma linha ligada prova e o que não prova

Um evento de arranque de serviço registra que a unidade local foi convidada a arrancar e que não terminou de imediato. Não registra um handshake concluído, uma chave de par válida ou uma rota funcional. Tomar essa linha como prova de um túnel é a leitura errada mais comum destes registos. A linha prova intenção e estado do processo, e absolutamente nada sobre alcançabilidade.

O estado de encaminhamento é uma observação separada, e vem da tabela de rotas e não de qualquer registo.

Um evento de adaptador pode explicar uma falha silenciosa: a interface subiu, o endereço foi atribuído e as rotas nunca foram instaladas porque uma regra de política as rejeitou. Nessa sequência, cada linha visível parece saudável enquanto nada é encaminhado, e a única forma de o ver é comparar os carimbos temporais do registo com a tabela de rotas no mesmo instante. Mantenha a ordem de eventos do próprio cliente ao lado de ambos, porque o cliente é a única fonte que sabe o que pediu. Os dois factos de que precisa em conjunto quase nunca aparecem na mesma linha.

Uma reconexão posterior sobrescreve a parte interessante deste quadro, por isso capture a janela na primeira falha em vez de depois de três tentativas.

Correlacione uma janela estreita

Anote a hora da tentativa com o respetivo fuso horário e depois extraia os poucos minutos em torno dela. O primeiro erro da janela precede quase sempre a linha de desligamento que os pedidos de suporte citam.

journalctl -u wg-quick@wg0 --since "today 09:00" --until "today 09:20"
ip route show table all | grep wg0
log show --last 20m --predicate 'subsystem == "com.apple.network"'

Cada comando responde a uma parte diferente da pergunta: o primeiro dá o ciclo de vida, o segundo o estado de encaminhamento, o terceiro o subsistema de rede do macOS. No Windows, filtre o registo do sistema pelo nome do fornecedor em vez de percorrer todo o canal, e exporte apenas os eventos correspondentes.

Mantenha o excerto suficientemente pequeno para que um leitor o possa seguir. Uma janela de vinte minutos com quatro eventos relevantes sustenta uma conclusão; uma exportação de um dia inteiro com milhares de linhas não sustenta nada.

Onde estes registos terminam

Os registos locais descrevem o dispositivo, não o caminho. Não podem mostrar o que um fornecedor guardou, se uma sessão foi associada a uma conta ou o que viu um destino. A afirmação de um fornecedor de que não guarda registos não diz nada sobre o sistema operativo do seu portátil, e um evento local não prova nada sobre os registos históricos do fornecedor.

Também transportam mais dados pessoais do que seria de esperar: nomes de utilizador, nomes de anfitrião, caminhos de montagem e identificadores de dispositivo aparecem em mensagens de sistema vulgares mesmo quando não há qualquer conteúdo de navegação. Remova esses dados antes de anexar algo a um pedido, e guarde o original sob controlos de acesso normais.

Num dispositivo gerido, peça o excerto relevante à equipa de TI em vez de tentar apagar o registo organizacional. O objetivo de diagnóstico é uma única pergunta estreita respondida por duas fontes, não um histórico completo da máquina.