Porque a sua VPN demora mais a recuperar do que a falha

O Wi-Fi voltou há trinta segundos e a VPN continua em baixo, por isso o cliente parece avariado. Muitas vezes está apenas a seguir o seu próprio calendário de novas tentativas, e esse calendário não sabe que a rede acabou de voltar. Essa lacuna é toda a história: o tempo de recuperação é a falha mais qualquer espera que o cliente já tenha aceitado. Baixar todos os temporizadores é uma resposta, e compreender qual temporizador importa é a outra.

Três condições decidem se o ajuste ajuda: qual etapa é lenta, se a falha é sequer repetível e como o cliente percebe que a rede voltou.

Três esperas que parecem uma

A resolução do ponto final, a negociação IKE ou TLS, a retransmissão de pacotes e iniciar uma nova tentativa são eventos separados com temporizadores separados. O strongSwan documenta o backoff de retransmissão para IKE, e o OpenVPN tem os seus próprios controlos de nova tentativa com uma semântica diferente. Copiar um número de um para o outro assume que os mecanismos coincidem, e não coincidem. Leia a sequência do registo antes de decidir que intervalo está a observar.

Um minuto de silêncio no registo não é necessariamente um processo congelado. Pode ser um backoff exponencial a fazer exatamente aquilo para que foi configurado.

Que etapa está realmente lenta?

Se o registo mostra tentativas a falhar com um erro de autenticação, nenhuma alteração de temporizador ajuda, porque a credencial está errada. Se não são feitas tentativas de todo, o cliente está dentro da sua janela de espera e o calendário é a solução. Se são feitas tentativas e estas expiram, o problema é a alcançabilidade ou um ouvinte em falta, e tentar mais depressa apenas enche o registo. Cada um desses três estados tem um dono diferente, e só um deles é um problema de temporização.

Classifique a falha antes de tocar num número.

Quando baixar um temporizador ajuda, e quando não

Baixe o limite de novas tentativas quando o custo dominante é a espera após uma falha curta e frequente, como um portátil a mover-se entre pontos de acesso. Deixe-o em paz quando as falhas são longas ou raras, porque tentar agressivamente acrescenta carga exatamente no momento em que o concentrador é menos capaz de responder. Em ambos os casos, altere um parâmetro, registe-o e meça a recuperação seguinte em vez de assumir que melhorou.

Um tempo limite muito baixo copiado para cada perfil é o estado final habitual de ajuste sem medição.

Verifique a prontidão antes de culpar o cliente

O cliente muitas vezes não consegue ver que a rede é utilizável até algo o tentar. Um portal cativo, uma renovação DHCP ou uma mudança de rota podem deixá-lo a esperar por um calendário definido antes de tudo isso acontecer. Observe a mudança de estado de rede do sistema operativo e a tentativa seguinte do cliente no mesmo relógio, e verá de quem é a espera. A versão rápida é anotar o carimbo temporal do evento de rede pronta e o carimbo temporal da primeira tentativa seguinte.

Confirme também que o tráfego direto continua bloqueado durante a espera, porque uma reconexão mais rápida que deixa escapar tráfego não é uma melhoria.

O que registar

Anote que temporizador mudou, de que valor para que valor, e como ficou a recuperação depois. Anote também a versão do cliente, porque os valores predefinidos mudam entre versões e um tempo limite muito baixo não documentado vai confundir a próxima pessoa que ler o perfil.

Esse registo transforma a próxima atualização de software numa comparação em vez de uma experiência.