Un conxelamento de dous segundos: foi a VPN ou o Wi-Fi?
Un bloqueo de dous segundos e unha nova sesión VPN son acontecementos distintos. Pon o camiño de acceso e o túnel en liñas de tempo separadas antes de cambiar un temporizador.
Un conxelamento de dous segundos que se recupera vese igual tanto se o túnel renegociou como se a radio tivo un soluço. Tamén é posible que non caese nada de nada, e esa posibilidade paga a pena probala primeiro. Unha ráfaga breve de perdas, unha renegociación e un bloqueo da aplicación séntense igual para a persoa que teclea. Só un dos tres casos se corrixe editando a configuración do túnel.
Dous rexistros, non un
Anota que lle aconteceu á conexión de debaixo e, por separado, que fixo o propio túnel. Despois sitúa a pausa da aplicación fronte a ambos os rexistros. Son series de acontecementos independentes que ás veces coinciden, e chamarlle desconexión aos tres supón a resposta desde o principio.
Un monitor que sonda unha vez por minuto non pode ver unha interrupción de dous segundos. Informar que ese día era saudable é tecnicamente exacto e practicamente inútil. Pon o intervalo de mostraxe xunto a cada resultado que cites.
Que fixo a ligazón de acceso mentres a aplicación se conxelaba
O intervalo de mostraxe e o tempo de espera definen que puido observar o monitor, así que anota ambos xunto ao resultado. Unha ausencia rexistrada de cortes significa pouco cando o instrumento mostraxa cada sesenta segundos. Despois sonda tres lugares con marcas de tempo: o router local, un host externo aprobado alcanzado polo camiño simple e un recurso detrás do túnel.
Confirma primeiro as rutas, porque un destino público pode estar el mesmo encamiñado polo túnel e entón mide o túnel en lugar do camiño de acceso. As probas que datan realmente o corte viven unha capa máis abaixo: acontecementos de ligazón no router, rexistros de resincronización no módem e un enderezo WAN que cambiou. Un contador acumulado de erros diche que algo fallou, nunca cando. Correlaciona eses rexistros coa xanela do incidente en vez de lelos illados.
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address show
Un contador que subiu onte non explica nada sobre un conxelamento desta mañá. Limita a correlación á xanela que o usuario reportou.
Busca o rexistro de reinicio
Un datagrama UDP perdido non fai, por si só, que Community OpenVPN inicie unha negociación TLS nova. O comportamento de reinicio segue ping-restart, e o valor vixente puido ser enviado polo servidor; o manual da 2.6 define eses temporizadores. A entrega rompe un instante, o limiar nunca se cruza e o rexistro queda baleiro. Por iso busca no rexistro arredor da pausa unha liña de reinicio, unha conexión nova ou un identificador de sesión que cambiou. Se non aparece ningún dos tres, o túnel probablemente non fixo nada e o temporizador nunca foi o problema.
Recortar cada keepalive fai que a detección pareza máis rápida e move a liña na que un soluço se converte en reconexión. Cada reconexión custa unha rolda de autenticación e a reinstalación de rutas. Estirar o temporizador non compra nada agás unha xanela máis longa na que un camiño morto aínda parece vivo. Ambas son decisións de axuste cun prezo, non melloras gratuítas.
Un acontecemento ausente tamén é unha proba, e é do tipo que a xente salta porque nada no rexistro lle chama a atención. Anota a busca que fixeches, non só o resultado.
Deixa que a comparación decida que arranxar
Cos dous rexistros un ao lado do outro, a asignación adoita escribirse soa. Un acontecemento de ligazón do router en ambos os camiños significa que o tema é a conexión de acceso. Un túnel silencioso e un camiño simple utilizábel significan que o é a negociación.
| 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 fila é unha pista, non un veredicto: os extremos despriorizan ICMP, e dous destinos non comparten necesariamente un camiño. Mantén os reloxos aliñados entre cliente, pasarela e aplicación para que a comparación sexa posible. Unha fila que encaixa en dúas columnas necesita outra observación, non unha decisión.
Un informe que sobrevive á revisión responde catro cousas: canto durou o conxelamento, que camiños seguiron respondendo, que rexistrou o túnel naquel segundo e con que frecuencia mostraxa o monitor. Eses catro feitos permiten ao seguinte lector reproducir a observación en lugar de confiar nun resumo. Unha porcentaxe de dispoñibilidade agocha exactamente o intervalo que che interesa, e a frase "a VPN caeu" tamén.