A VPN cai após uma renovação DHCP? Compare os endereços

Renovação da concessão e falha da VPN aparecem juntas nos logs com frequência suficiente para que as pessoas concluam que uma causa a outra. A coincidência temporal é real; a causalidade geralmente não. Uma renovação é uma solicitação unicast ao servidor que emitiu a concessão, pedindo para continuar com a mesma vinculação, e o servidor pode estendê-la sem que o cliente mude um único endereço. Examinar os valores do próprio cliente em torno do evento separa uma concessão renovada em silêncio de uma rede que realmente mudou sob um túnel em funcionamento.

Comece pelo cliente que caiu

Abra primeiro o log de conexão do cliente e anote o horário da queda ao segundo. Depois abra o log de rede do sistema operacional para o mesmo minuto e leia em ordem o que a interface fez. Essa ordem é toda a investigação: um evento DHCP antes da desconexão, uma desconexão antes do evento DHCP e dois eventos sem nada entre eles são três achados diferentes. Uma linha de log que apenas menciona a concessão enquanto o túnel já se reconectava é decoração, não prova.

Escreva a linha do tempo conforme avança em vez de mantê-la na memória. Marcas de tempo de ferramentas diferentes raramente coincidem perfeitamente, e o desvio em si às vezes é a explicação.

Compare os quatro valores em torno do evento

Quatro valores descrevem o lado local de uma conexão bem o suficiente para detectar uma mudança real: o endereço da interface, o gateway padrão, a lista de resolvedores e o estado operacional da interface. Capture-os no minuto seguinte à queda e compare com uma captura feita enquanto o túnel estava saudável.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Um endereço inalterado com gateway inalterado e lista de resolvedores alterada aponta para resolução de nomes e não para roteamento, e o túnel pode ter sobrevivido enquanto as aplicações deixaram de encontrar hosts. Um gateway alterado significa que o caminho de saída da rede local se moveu, o que basta para invalidar uma rota que apontava para o anterior. Se os quatro valores coincidirem com a captura saudável, a concessão não é a sua causa e a lógica de reconexão do próprio cliente passa a ser o assunto. Capture a comparação enquanto a falha está visível, porque uma captura saudável feita após uma reinicialização tem um histórico de endereços diferente e não coincidirá.

O que uma renovação pode e não pode mudar

RFC 2131 descreve a renovação como uma solicitação ao servidor original na metade do tempo de concessão, com revinculação a qualquer servidor aos sete oitavos se a primeira tentativa ficar sem resposta. Nenhuma das etapas exige que o cliente obtenha um endereço diferente, e um servidor cooperativo normalmente estende a vinculação existente. Uma mudança real de endereço geralmente chega por outro caminho: um servidor que recusa a renovação, um cliente que perdeu o estado e recomeçou, ou uma rede que moveu o dispositivo para outro segmento.

O lado público da conexão pode mudar sem nenhuma mudança local. Atrás de uma tradução de grau operadora, o endereço que o par da VPN vê pode ser reatribuído independentemente do que a concessão local fez, e essa reatribuição parece idêntica a uma falha de rede local por dentro do cliente. Comparar um endereço relatado localmente com uma observação do lado do par é a única forma de separá-los.

Quando o cliente não consegue se adaptar

Um cliente que vinculou seu transporte ao endereço antigo, armazenou em cache uma rota obsoleta para o par ou salvou uma identidade de interface pode continuar tentando um caminho que não existe mais. Isso é um defeito de adaptação, e é visível como retransmissões repetidas para um endereço que o host não consegue mais alcançar. Alguns clientes lidam com isso por design: o WireGuard, por exemplo, atualiza o endpoint de um par quando um pacote corretamente autenticado chega de uma nova origem.

Uma reinicialização manual que restaura o serviço é uma pista sobre onde a adaptação falhou, não uma prova de que concessões e túneis sejam incompatíveis. Mantenha a política de bloqueio durante o teste, ou o próprio teste se torna uma interrupção com outra causa. Registre se o cliente se recuperou sozinho, quanto tempo levou e qual endereço tentou de novo; essa sequência diz mais do que o motivo de desconexão mostrado na interface.

Repita o evento antes de culpá-lo

Reproduza a condição em vez de esperar o cronograma: libere e renove a concessão, ou force o evento controlado equivalente, e observe se o túnel sobrevive. Em uma rede gerenciada, coordene qualquer mudança de endereço com o proprietário da rede, porque uma atribuição estática arbitrária pode colidir com um dispositivo que já possui esse endereço.

Após uma correção suportada, repita o mesmo evento e depois teste um aplicativo e uma consulta de nome, porque um túnel que se reconecta mas quebra o DNS passa em um teste mais fraco do que o que importa. Relate a mudança específica que você observou, com sua marca de tempo, em vez de nomear a concessão programada como causa. A diferença entre esses dois relatos é se a próxima pessoa consegue reproduzir a falha ou apenas o boato.