Um congelamento de dois segundos: foi a VPN ou o Wi-Fi?
Um bloqueio de dois segundos e uma nova sessão VPN são eventos diferentes. Coloque o caminho de acesso e o túnel em linhas do tempo separadas antes de mudar um temporizador.
Um congelamento de dois segundos que se recupera parece igual, tanto se o túnel renegociou quanto se o rádio engasgou. Também é possível que nada tenha caído, e vale a pena testar essa possibilidade primeiro. Uma rajada curta de perdas, uma renegociação e um travamento de aplicativo são sentidos da mesma forma por quem está digitando. Só um dos três casos é corrigido editando a configuração do túnel.
Dois registros, não um
Anote o que aconteceu com a conexão por baixo e, separadamente, o que o próprio túnel fez. Depois coloque a pausa do aplicativo diante dos dois registros. São séries de eventos independentes que às vezes coincidem, e chamar os três de desconexão assume a resposta desde o início.
Um monitor que testa uma vez por minuto não consegue ver uma interrupção de dois segundos. Relatar que aquele dia estava saudável é tecnicamente correto e praticamente inútil. Coloque o intervalo de amostragem ao lado de cada resultado que você citar.
O que o link de acesso fez enquanto o aplicativo congelava
O intervalo de amostragem e o tempo limite definem o que o monitor poderia ter observado, então anote os dois ao lado do resultado. Uma ausência registrada de quedas significa pouco quando o instrumento amostra a cada sessenta segundos. Em seguida, teste três lugares com carimbos de tempo: o roteador local, um host externo aprovado alcançado pelo caminho simples e um recurso atrás do túnel.
Confirme primeiro as rotas, porque um destino público pode ele mesmo ser roteado pelo túnel e então mede o túnel em vez do caminho de acesso. As provas que realmente datam a queda ficam uma camada abaixo: eventos de link no roteador, registros de ressincronização no modem e um endereço WAN que mudou. Um contador acumulado de erros diz que algo deu errado, nunca quando. Correlacione esses registros com a janela do incidente em vez de lê-los isoladamente.
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address showUm contador que subiu ontem não explica nada sobre um congelamento desta manhã. Limite a correlação à janela que o usuário relatou.
Procure o registro de reinício
Um datagrama UDP perdido não faz, por si só, o Community OpenVPN iniciar uma nova negociação TLS. O comportamento de reinício segue ping-restart, e o valor em vigor pode ter sido imposto pelo servidor; o manual da 2.6 define esses temporizadores. A entrega quebra por um instante, o limite nunca é cruzado e o log fica vazio. Por isso procure no log em volta da pausa uma linha de reinício, uma conexão nova ou um identificador de sessão alterado. Se nenhum dos três aparecer, o túnel provavelmente não fez nada e o temporizador nunca foi o problema.
Encurtar cada keepalive faz a detecção parecer mais rápida e desloca a linha em que um engasgo vira reconexão. Cada reconexão custa uma rodada de autenticação e a reinstalação de rotas. Esticar o temporizador não compra nada além de uma janela maior em que um caminho morto ainda parece vivo. Ambas são decisões de ajuste com um preço, não melhorias gratuitas.
Um evento ausente também é prova, e é do tipo que as pessoas pulam porque nada no log chama atenção para ele. Anote a busca que você fez, não apenas o resultado.
Deixe a comparação decidir o que corrigir
Com os dois registros lado a lado, a atribuição costuma escrever-se sozinha. Um evento de link do roteador nos dois caminhos significa que o assunto é a conexão de acesso. Um túnel silencioso e um caminho simples utilizável significam que o assunto é a negociação.
| What you observed | Tunnel log at that second | Where to look next |
|---|---|---|
| two-second pause, plain path answers throughout | nothing | the monitor's resolution, then a loss burst |
| pause plus a router link event, plain path stops and returns | no restart line | the access link, not the tunnel timer |
| pause, then a new session identifier | restart line | the restart threshold and what triggered it |
| one application freezes while both paths answer | nothing | that application and its server-side work |
Cada linha é uma pista, não um veredito: os extremos rebaixam a prioridade do ICMP, e dois destinos não compartilham necessariamente um caminho. Mantenha os relógios alinhados entre cliente, gateway e aplicativo para que a comparação seja possível. Uma linha que cabe em duas colunas precisa de mais uma observação, não de uma decisão.
Um relatório que sobrevive à revisão responde a quatro coisas: quanto durou o congelamento, quais caminhos continuaram respondendo, o que o túnel registrou naquele segundo e com que frequência o monitor amostra. Esses quatro fatos permitem ao próximo leitor reproduzir a observação em vez de confiar num resumo. Uma porcentagem de disponibilidade esconde exatamente o intervalo que lhe interessa, e a frase "a VPN caiu" também.