Três relógios num só registo VPN: cliente, gateway, recolhedor

A linha temporal de um incidente VPN começa normalmente com dois carimbos temporais que diferem alguns minutos e com um ecrã que mostra outra hora. A tentação é escolher um como correto e reescrever o outro. Ambos podem estar certos, porque foram escritos por relógios diferentes sobre eventos diferentes. O mito é que uma VPN tem um só relógio; o trabalho é descobrir que componente escreveu cada campo.

O mito: a VPN tem um só relógio

O cliente escreve um evento quando tenta uma ligação. O gateway escreve um evento quando recebe ou aceita essa tentativa. O recolhedor escreve uma hora de chegada quando recebe a mensagem do gateway. São três eventos, e cada um é carimbado pelo relógio em que confiou o componente que o escreve. Colapsá-los numa única linha temporal é uma comodidade que esconde a divergência que está a tentar explicar.

Os números diferem normalmente de segundos a minutos, e isso é normal. O que importa é se a diferença é um atraso de entrega, um desvio do relógio ou um evento realmente diferente. Decidir qual está a ver exige a origem de cada campo, não uma opinião mais firme sobre qual máquina tem razão.

Leia a origem antes do valor

Antes de comparar valores, identifique quem produziu cada um e de que campo se trata. Uma mensagem syslog transporta um carimbo temporal da origem, como descreve RFC 5424, e o formato também pode transportar informação de qualidade do tempo que descreve a sincronização e a precisão. O mesmo formato permite que a origem não envie qualquer carimbo temporal quando não consegue ler a hora do sistema, o que é em si mesmo um sinal útil.

journalctl -o short-iso --utc -n 20
logger -t vpn-check "test event"

O cliente também pode enviar um valor de tempo como metadados da aplicação, e o serviço que o armazena deve rotulá-lo como declarado pelo cliente em vez de o tratar como verificado de forma independente. Esse rótulo é a diferença entre prova e afirmação. Ao exportar registos para um caso, mantenha juntos o nome do campo, a origem e o desvio. Reduzi-los a uma hora local cómoda destrói exatamente a informação de que precisa.

Pare se não conseguir dizer que componente escreveu um campo. Compará-lo com qualquer outra coisa é adivinhar.

A apresentação do fuso horário não é um instante diferente

O mesmo instante apresentado como 10:00Z e como 18:00+08:00 não é uma discrepância, e tratá-lo como tal faz perder meia jornada. Converta ambos para UTC antes de comparar e mantenha o texto original ao lado da conversão. Uma fração decimal de um lado e segundos inteiros do outro também não são um conflito. A precisão não é a exatidão: um valor com milissegundos pode vir de um relógio errado em minutos.

date -u +%FT%TZ
timedatectl

O atraso de entrega é a outra explicação habitual. O gateway registra quando aceitou a ligação, e o recolhedor registra quando a mensagem lhe chegou, por isso o intervalo entre os dois é tempo de transporte. Esse intervalo diz algo sobre o pipeline de registos, não sobre a sessão VPN. Rotule-o como hora de chegada e deixa de competir com a hora do evento.

Correlacione sem reescrever as provas

Conserve os carimbos temporais originais e acrescente uma coluna derivada se precisar de uma vista comum. Explique a conversão nas notas em vez de editar os registos de origem, porque a origem é o que um revisor posterior irá verificar. Preserve a hora de chegada do recolhedor separadamente onde quer que exista.

chronyc tracking
journalctl --utc -u openvpn-client@work -n 50 --no-pager

Alterar o relógio de um dispositivo não é um controlo de privacidade e não reescreve registos que outro sistema já detém. Também torna as provas de suporte mais difíceis de comparar, e pode quebrar as verificações de certificados e de código que dependem do tempo. Mantenha os relógios sincronizados para o funcionamento normal e trate qualquer desvio deliberado como uma falha a investigar. Se os dois registos parecerem fora de sequência, olhe para a sincronização do relógio e para a entrega antes de construir uma nova história.

O mito a abandonar é que exista um único tempo da VPN. Pergunte o que escreveu cada campo e o que aconteceu quando o fez, e a linha temporal passa a ser um conjunto de observações rotuladas em vez de uma contradição.