A VPN do router parece bem depois de uma queda de energia? Teste estas quatro camadas

Um router que acende depois de uma falha restaurou a sua configuração, não a sua conectividade. Depois de uma queda de energia, um router pode restaurar o perfil de VPN guardado antes de as dependências de que esse perfil precisa estarem prontas: o modem a montante pode ainda estar a treinar, o relógio pode estar errado e a autenticação pode não ter sido concluída. A luz do painel e a configuração guardada descrevem uma intenção, não um túnel a funcionar. Verifique as quatro camadas abaixo pela ordem em vez de substituir o perfil, porque é o que as pessoas fazem em segundo e lamentam em primeiro.

Tudo aqui pressupõe que está no local ou tem uma via de acesso que não depende do túnel que está a testar. Se não tiver, organize isso antes da próxima falha.

Primeira camada: a WAN voltou mesmo

Comece pelo modem, não pelo painel do router. Um router que termina o arranque antes de o modem ter treinado mostra uma interface saudável sem nada por trás, e o túnel não tem par para alcançar. Confirme que o modem está mesmo a encaminhar e depois confirme que o router assumiu as configurações de WAN que espera. Verifique também se o endereço WAN mudou: um endereço dinâmico que volta diferente pode invalidar uma regra baseada no endereço ou uma lista de permitidos remota, e de dentro da rede isso parece uma falha de VPN.

Algumas redes de acesso exigem também um novo passo de admissão depois de uma falha. Leia o registo do cliente para a primeira fase de falha em vez de adivinhar: o primeiro erro nomeia a camada, e tudo o que vem depois é consequência. Anote o endereço e o resultado da admissão no ticket, porque ambos decidem se o mesmo perfil funcionará amanhã. Um endereço alterado é uma correção de cinco minutos e um mistério de duas horas.

Segunda camada: verifique o relógio antes do certificado

Um relógio errado interfere na validade do certificado e em tudo o que depende do tempo, e um dispositivo incorporado que arranca sem uma fonte de tempo a funcionar pode ficar numa data antiga durante algum tempo. A validação do certificado falha então por um motivo que nada tem a ver com a credencial. Um erro de validade cujas datas estão desviadas em anos aponta para o relógio; o mesmo erro com datas atuais aponta para o certificado.

date -u
chronyc tracking

Use o processo de recuperação de tempo suportado e confirme o relógio do router antes de tocar no perfil. Desativar a validação para contornar o erro transforma um problema temporário de ordem num enfraquecimento permanente, e é a correção má mais comum neste cenário. Se o dispositivo não tiver relógio com bateria, a ordem de arranque importa: precisa de acesso à rede antes de sincronizar a hora, e de hora antes de validar um túnel. É essa ordem que deve ser corrigida se a mesma falha se repetir após cada queda.

Terceira camada: leia o que o túnel diz

Verifique o estado do próprio túnel e o resultado do aperto de mão ou da autenticação, não se a interface está ativa. Uma interface pode existir sem um par estabelecido, e um cliente pode mostrar-se ligado enquanto a renovação de chaves falha. Separe os tempos limite de transporte das rejeições explícitas: um tempo limite sugere que o caminho ou o par ainda não são alcançáveis, enquanto uma rejeição significa que o extremo remoto respondeu e recusou, muitas vezes por credenciais, um certificado ou uma identidade de par que já não corresponde. Enviar o utilizador para a reposição da palavra-passe por causa de um tempo limite desperdiça a tarde de todos.

Tenha à mão a última configuração boa conhecida para comparar campos em vez de os reconstruir. Se um campo mudou, essa mudança é o achado. Compare-o campo a campo com a restaurada em vez de ler apenas a restaurada. A maioria das surpresas depois de uma queda é um campo que voltou silenciosamente a um valor predefinido do modelo.

Quarta camada: teste a partir de um dispositivo a jusante

Abra um recurso permitido e inofensivo a partir de um cliente atrás do router e depois confirme que saída ou rota privada o tráfego realmente usou. Verifique o DNS e cada família de endereços que diz cobrir, porque a sonda do próprio router pode ter sucesso enquanto a política do cliente ainda está errada — a sonda usa muitas vezes outra fonte, outra tabela ou outro caminho de resolução.

curl -s https://ifconfig.me
nslookup example.com

Se o túnel estiver em baixo e não apenas mal configurado, decida se os clientes afetados devem ser bloqueados ou podem usar uma alternativa aprovada. Essa escolha pertence ao plano de comutação por falha antes de uma queda, não a um fio de conversa durante a mesma. Escreva a saída e o resolvedor observados no ticket da queda. Duas linhas agora poupam à pessoa seguinte uma hora de conjecturas sobre que caminho estava ativo na janela.

O que corrigir para que a próxima queda seja mais curta

Se a falha se repetir, a correção é a ordem, não a configuração: suba a WAN, depois o tempo, depois o túnel, depois a política do cliente. A maioria dos routers exprime isso como uma dependência ou um atraso, e um atraso curto e deliberado vence uma reescrita do perfil.

Depois repita o teste normal de reinício após a alteração, incluindo a verificação do lado do cliente. Um teste de reinício que olha apenas para o painel do router testa a camada menos informativa das quatro.