OpenVPN cai após uma renovação DHCP: mantenha a rota do endpoint

O túnel liga-se, depois uma renovação de aluguer no link de acesso mata-o, e o registo culpa um tempo limite em vez de uma rota. Nada na configuração da VPN mudou, e é essa a pista: algo fora dela mudou. Um evento DHCP reescreveu o endereço ou o gateway, e a rota de host que mantinha o endpoint do túnel acessível aponta agora para um salto seguinte que já não existe. Isto é um problema de propriedade antes de ser um problema de encaminhamento.

Compare o sintoma com as rotas meio predefinidas

Com redirect-gateway def1, o OpenVPN instala 0.0.0.0/1 e 128.0.0.0/1 em vez de substituir a rota predefinida. Juntas, essas duas cobrem todo o espaço de endereços, e vencem 0.0.0.0/0 só pelo comprimento do prefixo. Por isso qualquer destino sem uma correspondência mais específica entra no túnel.

O endpoint precisa de uma exceção. O OpenVPN acrescenta uma rota de host para o endereço do servidor através do gateway de acesso original antes de as meio predefinidas entrarem, para que os pacotes encapsulados possam sair. Quando essa exceção desaparece, ou mantém um salto seguinte que já não existe, os próprios pacotes exteriores do túnel correspondem a uma meio predefinida e são enviados de volta para dentro do túnel. O resultado é uma ligação que morre no próximo keepalive ou aperto de mão, sem nada no registo que pareça um erro de encaminhamento.

Confirme a forma da tabela antes de tocar em qualquer outra coisa. ip route show deve listar ambas as metades mais uma rota de host para o endereço do servidor; quando falta a rota de host, o resto da investigação tem um ponto de partida óbvio.

Porque é que as meio predefinidas vencem sem alterar a métrica

Uma métrica mais baixa não vence um prefixo mais longo. As rotas /1 vencem porque o kernel corresponde primeiro à rota mais específica, por isso subir uma métrica na rota predefinida não muda nada sobre para onde vai o tráfego destinado ao túnel. Perseguir métricas é o desvio errado mais comum neste diagnóstico.

Verifique a seleção com ip route get 203.0.113.10, substituindo pelo endereço real do servidor. A resposta nomeia a interface e o salto seguinte que o kernel usaria realmente, o que é mais informativo do que ler uma tabela e raciocinar sobre ela.

Execute esse comando antes de o túnel arrancar, enquanto ele está ativo e depois do evento de aluguer. Três respostas de um só comando, e o ponto de divergência torna-se visível.

Tire três instantâneos, não um

Recolha o endereço de acesso, o gateway de acesso, o destino do endpoint, a rota selecionada e quaisquer regras de política em três momentos: depois de o link de acesso ser configurado, depois de a VPN ligar e depois do evento de aluguer ou da operadora. Cada instantâneo é um punhado de comandos, e só fazem sentido juntos. Um único instantâneo após a falha regista o estado e não a transição. Escreva os comandos num script pequeno para que cada instantâneo seja tirado da mesma forma.

Guarde os instantâneos num só ficheiro com marcas temporais, porque a pergunta interessante mais tarde é a ordem. O evento DHCP chegou antes ou depois de o OpenVPN atualizar a sua rota? A resposta decide quem tem de o corrigir. Uma marca temporal de um relógio errado é pior do que nenhuma, por isso tire-a do host que é dono da tabela de encaminhamento.

Quando o endpoint está configurado como nome em vez de endereço, resolva-o também em cada instantâneo. Uma alteração de DNS no link de acesso pode mover o endpoint sem que qualquer rota seja tocada.

Decida que componente atualiza a exceção

Num sistema dhcpcd, os hooks correm a partir do diretório de hooks e do hook de saída, e o modo gestor difere em âmbito do modo por interface. Faça o que fizer o hook, tem de ser idempotente, porque as renovações podem chegar em rajadas.

O dono fiável é a integração que já conhece os dois lados: um gestor de rede que administra a ligação VPN, ou uma unidade ordenada depois de o link de acesso subir. Uma rota estática adicionada por um hook funciona até à próxima mudança de gateway e depois falha exatamente da mesma forma. Se usar mesmo um hook, faça-o ler o gateway atual em tempo de execução em vez de codificar o que viu hoje.

Registe o dono dentro da configuração. A próxima pessoa que depurar uma reconexão precisa de saber que é um hook, e não a VPN, o responsável pela rota de exceção.

Teste o ciclo de vida, não apenas a reconexão

Force uma renovação com dhcpcd -n eth0 ou libertando e renovando o aluguer, e depois verifique ip route get outra vez para o endpoint. Faça-o duas vezes, porque a segunda passagem apanha hooks que acrescentam rotas duplicadas. Depois reinicie, porque a persistência é uma propriedade diferente da correção.

Um túnel que sobrevive a uma renovação e a um reinício tem dono e uma exceção que funciona. O que só sobrevive a um reinício manual não tem nenhum dos dois, e falhará no próximo evento que não conseguir agendar.