Caídas intermitentes da VPN: que rexistrar en cada ocasión
Unha caída intermitente é un problema de datos antes ca un problema de configuración. Rexistre cinco campos por incidente e logo compare as etapas antes de cambiar axustes.
As caídas intermitentes son un problema de recollida de datos antes ca un problema de configuración. Rexistre os mesmos campos en cada aparición, ou os incidentes non se poderán comparar. Cambiar tres axustes despois de cada evento destrúe a única evidencia que tiña.
O procedemento seguinte tarda uns dous minutos por incidente e produce unha liña por evento. Supón acceso de só lectura nun dispositivo que vostede administra.
Fixe os campos antes do primeiro fallo
Redacte a lista de campos antes de que algo rompa, porque un modelo inventado a metade dun incidente sempre deixa fóra unha columna. Cinco campos abondan para comezar: a hora local co seu desfase, o desencadeante, a etapa que rompeu, o texto exacto do erro e se un intento novo tivo éxito.
O desencadeante merece o seu propio vocabulario: inactividade, reanudación tras a suspensión, cambio de rede, pico de carga, renovación de credenciais ou descoñecido. Deixe descoñecido etiquetado como descoñecido en lugar de enchelo despois de memoria. O campo de etapa achega o maior valor, porque rexistra onde se detivo a cadea e non que sentiu o usuario. O texto do erro debe copiarse literalmente, porque unha paráfrase perde a distinción entre dous códigos parecidos.
Deixe os ocos como ocos. Un modelo que obriga a responder convida a inventar, e un contexto inventado é peor ca un espazo en branco.
| Field | Example | Why it earns its place |
|---|---|---|
| Time with offset | 2026-11-03T09:14+08:00 | Orders events across sources in different zones |
| Trigger | resume from sleep | Separates a cause from a coincidence |
| Stage | handshake ok, no route | Names the boundary that failed |
Rexistre os mesmos cinco feitos no fallo
Execute as mesmas ordes na mesma orde cada vez. Dous minutos de saída valen máis ca unha foto da icona da bandexa, e a secuencia importa cando despois as marcas de tempo non coinciden.
date -Is journalctl -u wg-quick@wg0 --since "-2 min" --no-pager wg show wg0 latest-handshakes transfer ip route get 203.0.113.10 ping -c 3 -W 2 192.0.2.1
A primeira liña marca a observación cun desfase, e é a única forma de conciliar tres fontes rexistradas en zonas distintas. O extracto do rexistro cobre o ciclo de vida do servizo, e a liña do aperto de mans di se o par respondeu. A consulta de ruta nomea a interface que usaría un destino concreto, e iso non é o mesmo feito ca a existencia da interface. Un ping ao enderezo do túnel mostra se algo cruza a ligazón, non se o outro lado é accesible.
Escriba unha liña por incidente nun rexistro continuo, con eses campos e nada máis. Despois de cinco ou seis entradas, ordene por desencadeante e logo por etapa. Os patróns aparecen como pares repetidos, e un par que nunca se repite é probablemente unha coincidencia.
Localice a etapa que rompeu
A conectividade local, o estado do par, as rutas e a resolución de nomes fallan en sitios distintos, e cada un deixa a súa propia pegada. Se a interface existe pero ningunha ruta apunta a ela, o fallo é de política local. Se a marca de tempo do aperto de mans deixa de avanzar mentres a interface segue activa, o fallo está máis arriba.
A resolución de nomes pertence ao mesmo rexistro. Un resolutor que o luns seguía o túnel e o martes a rede local produce fallos que parecen aleatorios na capa de aplicación.
Para o acceso autorizado ao servidor, correlacione o mesmo intento e non unha reconexión próxima. Conserve as marcas de tempo orixinais e anote calquera desfase por separado, porque convertelas no sitio borra a evidencia da conversión. Un intento, un xogo de marcas de tempo, unha conclusión.
Compare unha condición cada vez
Unha comparación controlada cambia unha condición significativa e mantén a execución fallida xunto á exitosa. Mova o dispositivo a outra rede, ou desactive unha exclusión, e non cambie nada máis no mesmo paso.
Manteña a execución fallida no rexistro. Borrala a favor da que funciona descarta a única evidencia do límite que intenta localizar.
Comparta un extracto, non o perfil
Antes de enviar nada, quite contrasinais, testemuños, claves privadas, identidades alleas e cargas útiles. Un perfil completo é un segredo de configuración e non un resumo de conexión, e non pertence a un ticket.
Envie o extracto cos cinco campos e diga que etapa cre que fallou. Así un administrador pode examinar o límite que vostede nomeou en lugar de desprazarse por capturas dunha icona desconectada. Se o límite segue sen estar claro, o seguinte paso é outro rexistro controlado, non outro cambio de axustes.