Un túnel que mor cada quinze minuts, o cada hora al mateix minut, us diu que ha caducat algun temporitzador i no que la xarxa sigui inestable. El moviment útil és anotar l'interval i comparar-lo amb els quatre temporitzadors que produeixen aquest patró. Canviar els temps d'espera abans d'aquesta comparació normalment mou la fallada sense explicar-la, cosa que fa la propera ocurrència més difícil de llegir que la primera. El mesurament costa deu minuts i substitueix una setmana d'endevinalles.

Convertiu l'interval en un número

Recolliu cinc o sis ocurrències i calculeu el buit entre elles, no el buit des de l'inici del dia. Una caiguda a les 09:12, 10:12 i 11:12 és un límit horari; una caiguda a les 09:12, 09:27 i 09:42 és de quinze minuts des de l'última connexió correcta. Arrodoniu el resultat al temporitzador més plausible, no al minut més proper.

Registreu dos moments per esdeveniment: quan es va moure el trànsit per última vegada i quan el client va informar de la desconnexió. Aquests difereixen quan un túnel mor en silenci i el client només ho nota al següent enviament, i aquesta diferència és el que separa un temps d'espera d'inactivitat d'una fallada dura. Un client que nota tard infla la finestra d'inactivitat que mesureu.

Fixeu-vos si la reconnexió és automàtica. Un client que es reconnecta en segons manté l'interval visible al registre i fora de l'informe d'usuari, i per això aquestes fallades sovint es descriuen com a ocasionals i no pas periòdiques. També amaga l'esdeveniment de la persona que fa servir l'ordinador portàtil.

Quatre temporitzadors que semblen iguals

Gairebé tota caiguda repetida del túnel prové d'un d'aquests: una renovació de claus del protocol, una caducitat de mapatge inactiu, un esdeveniment de DHCP o d'interfície, o una política de compte. Es diferencien en si hi havia trànsit i en què diu el registre a la frontera.

Les signatures següents val la pena aprendre-les, perquè us permeten rebutjar tres explicacions amb una sola línia de registre:

TimerTypical triggerWhat the log shows at the boundary
Protocol rekeyTraffic present, fixed intervalNegotiation lines, sometimes a failure
NAT or firewall idleNo traffic for minutesSilence, then a timeout on send
DHCP lease or link changeHalf the lease, or a radio eventAddress or interface churn
Account session limitWall-clock hours since loginClean disconnect, server-side reason

La primera fila és un mecanisme de seguretat que fa la seva feina, i la segona és un dispositiu intermediari que oblida l'estat. Confondre'ls porta o bé a debilitar la renovació o bé a perseguir una regla de tallafoc que no hi era mai.

Ocupat contra inactiu us diu quina meitat

Feu una comparació controlada amb trànsit continu, com ara un flux llarg cap a un amfitrió dins del túnel, i observeu si l'interval canvia. Si la caiguda desapareix mentre flueixen les dades, el temporitzador es basa en la inactivitat.

Si sobreviu al trànsit continu, el disparador pertany a la renovació, la concessió o la política. Aquesta única prova elimina la meitat dels candidats en aproximadament una hora d'observació, i no costa res més que atenció.

Manteniu la xarxa d'accés sense canvis durant la prova. Passar entre Wi-Fi i Ethernet a mig camí de la comparació introdueix exactament l'esdeveniment d'interfície que intenteu distingir d'un temporitzador.

Igualeu la línia de registre amb la frontera

Llegiu els registres del client i del servidor al voltant del moment anotat, no el fitxer sencer. Una renovació mostra negociació; una caducitat d'inactivitat no mostra res fins al paquet següent; un canvi de concessió mostra feina d'adreça; un límit de política normalment mostra una desconnexió administrativa neta.

Aquestes ordres extreuen la finestra rellevant de cada font:

grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg show

Si les tres fonts coincideixen en la marca de temps, teniu l'amo del temporitzador. Si només el registre del client té alguna cosa, probablement el servidor no és qui acaba la sessió.

Repareu l'etapa, no la icona

Cada amo té una reparació suportada. Una fallada de renovació necessita propostes compatibles als dos extrems. Una caducitat d'inactivitat necessita una senyal de manteniment o una expectativa d'inactivitat més curta, dins del que permet el camí. Un esdeveniment de concessió necessita que s'ajustin la interfície o els paràmetres d'energia. Un límit de compte és una decisió de política, no un error.

Desactivar la renovació o l'autenticació per mantenir la icona verda canvia una caiguda visible per una debilitat invisible, i us deixa sense poder dir quan el túnel va negociar claus noves per última vegada. Torneu a provar la durada original després i conserveu les marques de temps, perquè el proper esdeveniment es pugui comparar amb aquest en lloc de començar de zero.

Articles relacionats