Por que un túnel de Azure OpenVPN cae aproximadamente cada sesenta segundos
Un túnel que cae cada sesenta segundos rematou a súa aperta de mans, así que nada o bloquea. Le primeiro o motivo da desconexión e despois compara os dous temporizadores keepalive.
O túnel remata a súa aperta de mans, transporta tráfico durante aproximadamente un minuto e despois reconéctase. Esa secuencia descarta o sospeitoso habitual, porque unha devasa que bloquease o porto tería detido a aperta de mans e non a sesión. O que tes é un desacordo sobre a vitalidade: un lado decidiu que o outro quedara en silencio e derrubou un túnel que funcionaba. A liña do rexistro di que lado, e iso escolle a solución.
Le esa liña antes de tocar ningún temporizador.
O mito: algo na ruta bloquea o túnel
Se un porto estivese bloqueado, a conexión fallaría ao principio e seguiría fallando. Un ciclo repetido significa que as mensaxes de control flúen, que as sesións se establecen e que algo máis adiante na conversación non deixa de caducar. O bloqueo produce silencio, e isto produce un ritmo.
O ritmo é a pista útil. Os temporizadores prodúceo; a perda de paquetes raramente.
Le o motivo da desconexión antes que o temporizador
OpenVPN nomea o seu motivo, e cada nome apunta a un subsistema distinto. Session invalidated: KEEPALIVE_TIMEOUT é un temporizador que caduca, así que compara os valores de ping e ping-restart nos dous extremos. AUTH_FAILED son credenciais ou o estado do certificado, e ningún cambio de temporizador axudará. Un erro TLS significa que os pares nin sequera chegaron á fase keepalive.
Anota a hora de conexión, a hora de desconexión e se o intervalo é estable ao segundo. Esa única medición separa un horario configurado dunha coincidencia.
Un intervalo estable é un temporizador. Un que deriva é máis probablemente un problema de ruta ou unha sesión desprazada.
Dous temporizadores keepalive que nunca se puxeron de acordo
Os perfís exportados desde o portal ás veces aínda levan liñas como keepalive ou ping-restart copiadas dun modelo de servidor comunitario. A pasarela executa a súa propia detección de par morto e impón as súas propias expectativas, e os dous horarios non teñen que coincidir. Cando discrepan, o cliente reiníciase segundo un horario que a pasarela nunca aceptou.
Os dous valores non son o mesmo control. ping é a frecuencia coa que o cliente envía un eco, e ping-restart é canto espera sen oír nada antes de derrubar o túnel. Un perfil cun ping-restart curto e unha pasarela que responde amodo reiniciaranse en cada período de silencio, que é exactamente a forma dun ciclo dun minuto.
O cambio mínimo no lado do cliente é neutralizar os temporizadores no nivel superior do perfil, fóra de cada bloque en liña:
keepalive 0 0Garda, recarga o perfil, volve conectar. Unha sesión que xa está na memoria conserva os valores antigos, e por iso ás veces parece que a edición non fixo nada.
O nome do certificado pode moverse baixo os teus pés
A autenticación por certificado de Azure depende de que o cliente confíe no nome que a pasarela presenta hoxe. Unha liña verify-x509-name nunha descarga antiga pode fixar un nome que unha reconstrución da pasarela ou unha renovación do certificado cambiou desde entón, e o desaxuste maniféstase como un bucle de reconexión e non como un erro claro. Borrar a liña restaura a conectividade, o que a converte nun bo diagnóstico e unha mala solución permanente, porque tamén elimina a verificación. Cando o túnel aguante, restaura a liña co nome que a pasarela presenta realmente.
Proba unha segunda xeración de cliente na mesma máquina antes de editar a pasarela. Se un cliente entra en bucle e o outro aguanta, o problema non é o perfil.
Que cambiar e en que orde
Comproba despois se hai unha sesión desprazada. Dous dispositivos que comparten un certificado poden expulsarse mutuamente, e o resultado parece periódico porque ambos os lados seguen reconectándose. Compara os rexistros de sesión de punto a sitio da mesma identidade que aparece unha e outra vez.
Despois proba a ruta inactiva executando tráfico continuo durante varios minutos. Se as caídas se deteñen mentres flúe o tráfico, o temporizador que importa pertence a un dispositivo NAT ou a un balanceador de carga da ruta, non a OpenVPN.
Só despois desas catro probas se deberían cambiar os axustes da pasarela.