O IP WAN mudou e o túnel caiu: as verificações por ordem

O túnel cai, o router regista uma reconexão e nada na LAN se moveu. Um novo endereço WAN invalida a ligação exterior sem mudar nada lá dentro: o endereço de origem do cliente mudou, o estado NAT antigo aponta para uma origem que já não existe e o par remoto pode continuar a enviar para o endereço anterior. A recuperação é um comportamento normal, e a pergunta útil é qual estado não foi atualizado.

Nomeie o evento antes de ler o registo

Verifique o que aconteceu realmente na camada de acesso. Uma renovação do lease do ISP é um evento. Uma sessão PPPoE que se voltou a ligar é outro. Um modem de fibra reiniciado, ou uma comutação por falha de WAN de um uplink para outro, muda o endereço exterior ou o seu caminho de uma terceira forma. Não são o mesmo evento e não deixam o mesmo resíduo.

Uma linha de reconexão no registo do VPN também não é prova de uma mudança de WAN. Um tempo limite de inatividade, um intervalo de reautenticação e a deteção de par morto produzem todos reconexões sem qualquer mudança de endereço. Compare as marcas temporais do registo de acesso com o registo do VPN antes de concluir algo, e mantenha a janela de comparação suficientemente larga para apanhar uma mudança que ocorreu durante a noite.

O roaming e a reconexão são protocolos diferentes

O WireGuard tem roaming autenticado integrado no protocolo: quando um par recebe um pacote corretamente autenticado de um novo endereço de origem, atualiza o ponto final desse par. O início rápido do WireGuard descreve a configuração do par que torna isto possível, e é por isso que um cliente num endereço variável muitas vezes recupera sem um reinício visível.

O OpenVPN comporta-se de forma diferente por omissão. Uma sessão UDP pode terminar e voltar a ligar-se, e o comportamento float opcional permite que um par autenticado continue a partir de um novo endereço onde a configuração o permite. Os túneis baseados em TCP são mais rígidos, porque a própria ligação está ligada ao par de endereços. Essa diferença decide se a recuperação parece invisível ou se anuncia no registo sempre.

Nenhum dos comportamentos diz nada sobre as aplicações lá dentro. Um túnel recuperado não restaura uma sessão TCP que o par já considerava morta.

Estado que o túnel não possui

O estado de tradução e de encaminhamento sobrevive à reconexão de formas que surpreendem. Uma entrada conntrack criada para a origem antiga mantém o caminho de resposta ancorado num endereço que já não existe, e expira segundo o seu próprio calendário, não quando o túnel voltou. Reiniciar o serviço do túnel não encurta essa espera, por isso uma ligação reparada ainda pode parecer avariada durante algum tempo.

As rotas e as regras de política podem referenciar a gateway ou a interface antigas. Um conjunto de regras que estava correto antes de uma mudança de WAN pode apontar para um dispositivo que agora está em baixo, o que produz um túnel que se declara ligado e tráfego que não vai a lado nenhum. O DNS dinâmico para um servidor que aloja é um problema separado do de um cliente que obtém uma nova origem. O registo tem de ser atualizado para que os clientes remotos o encontrem, e nenhuma configuração do lado do cliente compensa um endereço que a tradução a montante não reencaminhará.

Ordene as verificações de fora para dentro

A ordem abaixo vai da ligação exterior para dentro, e parar no primeiro passo que falha é o que a torna útil: cada verificação exclui a camada acima. Mantenha essa ordem mesmo quando a falha pareça óbvia.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

O primeiro comando mostra o ponto final atual e a idade do handshake para cada par. O segundo e o terceiro mostram se a interface exterior e a rota até ao ponto final ainda fazem sentido. A contagem de conntrack é uma verificação grosseira do estado que resta do endereço anterior, e o registo do sistema é onde o motivo da reconexão fica registado.

Depois teste a partir de um cliente da LAN e não do router. Um ping originado pelo próprio router usa um caminho diferente do tráfego reencaminhado, por isso um ping bem-sucedido a partir do router prova que o túnel existe e nada sobre a acessibilidade do cliente.

Decida o comportamento esperado e escreva-o

Reconectar é o comportamento correto para a maioria das implementações, por isso o objetivo não é impedi-lo. Decida antes o que deve acontecer ao tráfego durante a interrupção: pará-lo, retê-lo ou passar para outro caminho. Essa decisão pertence à firewall e à política de encaminhamento, não ao perfil VPN.

Registe os eventos de acesso e as horas de reconexão em conjunto durante uma semana. Mudanças repetidas sem um evento de acesso correspondente apontam para o serviço de acesso, e substituir o perfil VPN não corrige um uplink que não para de renegociar. Um único par de entradas no mesmo minuto resolve a questão para esse incidente e dá uma linha de base ao seguinte.