O VPN desconéctase co mesmo intervalo? Iguala o temporizador
Unha caída a intervalo fixo é unha pegada. Compare a renovación de claves do túnel, o temporizador de inactividade de NAT, a concesión DHCP e o límite da conta antes de cambiar nada.
Un túnel que morre cada quince minutos, ou cada hora no mesmo minuto, dinos que caducou algún temporizador, non que a rede sexa inestable. O movemento útil é anotar o intervalo e comparalo cos catro temporizadores que producen este patrón. Cambiar os tempos de espera antes desa comparación adoita mover o fallo sen explicalo, o que fai a seguinte ocorrencia máis difícil de ler que a primeira. A medición custa dez minutos e substitúe unha semana de conxecturas.
Converta o intervalo nun número
Reúna cinco ou seis ocorrencias e calcule o oco entre elas, non o oco desde o inicio do día. Unha caída ás 09:12, 10:12 e 11:12 é un límite horario; unha caída ás 09:12, 09:27 e 09:42 son quince minutos desde a última conexión correcta. Redondee o resultado ao temporizador máis plausible, non ao minuto máis próximo.
Rexiste dous momentos por evento: cando se moveu o tráfico por última vez e cando o cliente informou da desconexión. Diferéncianse cando un túnel morre en silencio e o cliente só o nota no seguinte envío, e esa diferenza é o que separa un tempo de espera por inactividade dun fallo duro. Un cliente que nota tarde incha a xanela de inactividade que vostede mide.
Fíxese en se a reconexión é automática. Un cliente que se reconecta en segundos mantén o intervalo visible no rexistro e fóra do informe do usuario, e por iso estes fallos adoitan describirse como ocasionais e non periódicos. Tamén oculta o evento á persoa que usa o portátil.
Catro temporizadores que se parecen
Case toda caída repetida do túnel vén dun destes: unha renovación de claves do protocolo, unha caducidade de mapeamento inactivo, un evento de DHCP ou de interface, ou unha política de conta. Diferéncianse en se había tráfico e no que di o rexistro no límite.
As sinaturas seguintes merecen aprenderse, porque permiten descartar tres explicacións cunha soa liña de rexistro:
| Timer | Typical trigger | What the log shows at the boundary |
|---|---|---|
| Protocol rekey | Traffic present, fixed interval | Negotiation lines, sometimes a failure |
| NAT or firewall idle | No traffic for minutes | Silence, then a timeout on send |
| DHCP lease or link change | Half the lease, or a radio event | Address or interface churn |
| Account session limit | Wall-clock hours since login | Clean disconnect, server-side reason |
A primeira fila é un mecanismo de seguridade que fai o seu traballo, e a segunda é un dispositivo intermedio que esquece o estado. Confundilos leva a debilitar a renovación ou a perseguir unha regra de cortalumes que nunca estivo implicada.
Ocupado fronte a inactivo dille que metade
Faga unha comparación controlada con tráfico continuo, como un fluxo longo cara a un host dentro do túnel, e observe se o intervalo cambia. Se a caída desaparece mentres flúen os datos, o temporizador baséase na inactividade.
Se sobrevive ao tráfico continuo, o disparador pertence á renovación, á concesión ou á política. Esa única proba elimina a metade dos candidatos en aproximadamente unha hora de observación, e non custa nada máis que atención.
Manteña a rede de acceso sen cambios durante a proba. Pasar entre Wi-Fi e Ethernet a metade da comparación introduce exactamente o evento de interface que intenta distinguir dun temporizador.
Iguale a liña de rexistro co límite
Lea os rexistros do cliente e do servidor arredor do momento anotado, non o ficheiro completo. Unha renovación mostra negociación; unha caducidade por inactividade non mostra nada ata o seguinte paquete; un cambio de concesión mostra traballo de enderezo; un límite de política adoita mostrar unha desconexión administrativa limpa.
Estes comandos extraen a xanela relevante de cada fonte:
grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg showSe as tres fontes coinciden na marca de tempo, ten o dono do temporizador. Se só o rexistro do cliente ten algo, probablemente o servidor non sexa o que termina a sesión.
Arranxe a etapa, non a icona
Cada dono ten unha reparación admitida. Un fallo de renovación necesita propostas compatibles nos dous extremos. Unha caducidade por inactividade necesita un sinal de mantemento ou unha expectativa de inactividade máis curta, dentro do que permite a ruta. Un evento de concesión necesita que se axisten a interface ou os parámetros de enerxía. Un límite de conta é unha decisión de política, non un erro.
Desactivar a renovación ou a autenticación para manter a icona verde cambia unha caída visible por unha debilidade invisible, e déixalle sen poder dicir cando o túnel negociou claves novas por última vez. Volva probar a duración orixinal despois e conserve as marcas de tempo, para que o próximo evento se poida comparar con este en lugar de empezar de cero.