Por que a túa VPN tarda máis en recuperarse que a caída

O Wi-Fi volveu hai trinta segundos e a VPN segue caída, así que o cliente parece avariado. A miúdo só segue o seu propio calendario de reintentos, e ese calendario non sabe que a rede acaba de volver. Esa fenda é toda a historia: o tempo de recuperación é a caída máis calquera espera que o cliente xa asumise. Baixar todos os temporizadores é unha resposta, e entender que temporizador importa é a outra.

Tres condicións deciden se o axuste axuda: que etapa é lenta, se o fallo é reintentable sequera e como se entera o cliente de que a rede volveu.

Tres esperas que parecen unha

A resolución do punto final, a negociación de IKE ou TLS, a retransmisión de paquetes e iniciar un intento novo son eventos separados con temporizadores separados. strongSwan documenta o retroceso de retransmisión para IKE, e OpenVPN ten os seus propios controis de reintento cunha semántica distinta. Copiar un número dun a outro supón que os mecanismos coinciden, e non coinciden. Le a secuencia do rexistro antes de decidir que intervalo estás mirando.

Un minuto de silencio no rexistro non é necesariamente un proceso conxelado. Pode ser un retroceso exponencial facendo exactamente aquilo para o que se configurou.

Que etapa é realmente lenta?

Se o rexistro mostra intentos que fallan cun erro de autenticación, ningún cambio de temporizador axuda, porque a credencial é incorrecta. Se non se fan intentos en absoluto, o cliente está dentro da súa xanela de espera e o calendario é a solución. Se se fan intentos e se esgotan, o problema é a alcanzabilidade ou un oínte ausente, e reintentar máis rápido só enche o rexistro. Cada un deses tres estados ten un dono distinto, e só un deles é un problema de sincronización.

Clasifica o fallo antes de tocar un número.

Cando axuda baixar un temporizador e cando non

Baixa o teito de reintentos cando o custo dominante é a espera tras unha caída breve e frecuente, como un portátil que se move entre puntos de acceso. Déixao en paz cando os fallos son longos ou raros, porque reintentar con agresividade engade carga xusto no momento en que o concentrador é menos capaz de responder. En ambos os casos, cambia un parámetro, rexístrao e mide a seguinte recuperación en lugar de supor que mellorou.

Un tempo de espera moi baixo copiado en cada perfil é o estado final habitual do axuste sen medición.

Comproba a dispoñibilidade antes de culpar o cliente

O cliente a miúdo non pode ver que a rede é utilizábel ata que algo o intenta. Un portal cautivo, unha renovación de DHCP ou un cambio de ruta poden deixalo esperando un calendario fixado antes de que ocorrese nada diso. Observa o cambio de estado de rede do sistema operativo e o seguinte intento do cliente no mesmo reloxo, e verás de quen é a espera. A versión rápida é anotar a marca de tempo do evento de rede lista e a marca de tempo do primeiro intento posterior.

Confirma tamén que o tráfico directo segue bloqueado durante a espera, porque unha reconexión máis rápida que filtra tráfico non é unha mellora.

Que rexistrar

Anota que temporizador cambiou, de que valor a que valor, e como se viu a recuperación despois. Anota tamén a versión do cliente, porque os valores por defecto móvense entre versións e un tempo de espera moi baixo non documentado confundirá a seguinte persoa que lea o perfil.

Ese rexistro converte a próxima actualización de software nunha comparación en lugar dun experimento.