Porque é que um túnel Azure OpenVPN cai aproximadamente a cada sessenta segundos
Um túnel que cai a cada sessenta segundos terminou o handshake, por isso nada o bloqueia. Leia primeiro o motivo da desconexão e depois compare os dois temporizadores keepalive.
O túnel termina o handshake, transporta tráfego durante cerca de um minuto e depois volta a ligar-se. Essa sequência elimina o suspeito habitual, porque uma firewall que bloqueasse a porta teria parado o handshake e não a sessão. O que tem é um desacordo sobre a vitalidade: um lado decidiu que o outro ficou em silêncio e derrubou um túnel que funcionava. A linha do registo diz qual lado, e é ela que escolhe a correção.
Leia essa linha antes de tocar em qualquer temporizador.
O mito: algo no caminho está a bloquear o túnel
Se uma porta estivesse bloqueada, a ligação falharia logo no início e continuaria a falhar. Um ciclo repetido significa que as mensagens de controlo circulam, que as sessões se estabelecem e que algo mais adiante na conversa não para de expirar. O bloqueio produz silêncio, e isto produz um ritmo.
O ritmo é a pista útil. Os temporizadores produzem-no; a perda de pacotes raramente.
Leia o motivo da desconexão antes do temporizador
OpenVPN dá nome ao seu motivo, e cada nome aponta para um subsistema diferente. Session invalidated: KEEPALIVE_TIMEOUT é um temporizador a expirar, por isso compare os valores de ping e ping-restart nos dois extremos. AUTH_FAILED são credenciais ou o estado do certificado, e nenhuma alteração de temporizador ajudará. Um erro TLS significa que os pares nunca chegaram à fase keepalive.
Registe a hora de ligação, a hora de desconexão e se o intervalo é estável ao segundo. Essa única medição separa um horário configurado de uma coincidência.
Um intervalo estável é um temporizador. Um que deriva é mais provavelmente um problema de caminho ou uma sessão deslocada.
Dois temporizadores keepalive que nunca concordaram
Os perfis exportados do portal às vezes ainda trazem linhas como keepalive ou ping-restart copiadas de um modelo de servidor comunitário. O gateway executa a sua própria deteção de par morto e impõe as suas próprias expectativas, e os dois horários não têm de coincidir. Quando divergem, o cliente reinicia segundo um horário que o gateway nunca aceitou.
Os dois valores não são o mesmo controlo. ping é a frequência com que o cliente envia um eco, e ping-restart é quanto tempo espera sem ouvir nada antes de derrubar o túnel. Um perfil com um ping-restart curto e um gateway que responde devagar vão reiniciar em cada período de silêncio, o que é exatamente a forma de um ciclo de um minuto.
A alteração mínima do lado do cliente é neutralizar os temporizadores no nível superior do perfil, fora de cada bloco inline:
keepalive 0 0Guarde, recarregue o perfil, volte a ligar. Uma sessão que já está na memória mantém os valores antigos, e é por isso que a edição às vezes parece não ter feito nada.
O nome do certificado pode mudar debaixo dos seus pés
A autenticação por certificado do Azure depende de o cliente confiar no nome que o gateway apresenta hoje. Uma linha verify-x509-name numa transferência mais antiga pode fixar um nome que uma reconstrução do gateway ou uma renovação do certificado alterou desde então, e a discrepância manifesta-se como um ciclo de reconexão e não como um erro claro. Apagar a linha restaura a conectividade, o que a torna um bom diagnóstico e uma má correção permanente, porque também remove a verificação. Quando o túnel se mantiver, reponha a linha com o nome que o gateway apresenta realmente.
Teste uma segunda geração de cliente na mesma máquina antes de editar o gateway. Se um cliente entrar em ciclo e o outro se mantiver, o perfil não é o problema.
O que alterar e por que ordem
Verifique a seguir se há uma sessão deslocada. Dois dispositivos que partilham um certificado podem expulsar-se um ao outro, e o resultado parece periódico porque os dois lados continuam a reconectar-se. Compare os registos de sessão de ponto para local da mesma identidade que aparece vezes sem conta.
Depois teste o caminho inativo executando tráfego contínuo durante vários minutos. Se as quedas pararem enquanto o tráfego flui, o temporizador que importa pertence a um dispositivo NAT ou a um balanceador de carga no caminho, e não ao OpenVPN.
As definições do gateway só devem mudar depois destes quatro testes.