Un tunel care moare la fiecare cincisprezece minute, sau la fiecare oră în aceeași minută, îți spune că a expirat un cronometru, nu că rețeaua este instabilă. Mișcarea utilă este să notezi intervalul și să îl compari cu cele patru cronometre care produc acest model. Schimbarea limitelor de timp înainte de acea comparație mută de obicei defectul fără a-l explica, ceea ce face următoarea apariție mai greu de citit decât prima. Măsurătoarea durează zece minute și înlocuiește o săptămână de presupuneri.

Transformă intervalul într-un număr

Adună cinci sau șase apariții și calculează distanța dintre ele, nu distanța de la începutul zilei. O cădere la 09:12, 10:12 și 11:12 este o limită orară; o cădere la 09:12, 09:27 și 09:42 este de cincisprezece minute de la ultima conexiune reușită. Rotunjește rezultatul la cel mai plauzibil cronometru, nu la cea mai apropiată minută.

Notează două momente pentru fiecare eveniment: când s-a mișcat ultima dată traficul și când clientul a raportat deconectarea. Ele diferă atunci când un tunel moare în tăcere și clientul observă abia la următoarea trimitere, iar această diferență separă un timeout de inactivitate de o defecțiune dură. Un client care observă târziu umflă fereastra de inactivitate pe care o măsori.

Observă dacă reconectarea este automată. Un client care se reconectează în câteva secunde ține intervalul vizibil în log și în afara raportului utilizatorului, motiv pentru care aceste defecțiuni sunt adesea descrise ca ocazionale, nu periodice. Ascunde evenimentul și de persoana care folosește laptopul.

Patru cronometre care arată la fel

Aproape fiecare cădere repetată a tunelului vine de la unul dintre acestea: reînnoirea cheilor protocolului, expirarea unei mapări inactive, un eveniment DHCP sau de interfață, sau o politică de cont. Ele diferă prin dacă exista trafic și prin ce spune logul la limită.

Semnăturile de mai jos merită învățate, pentru că îți permit să respingi trei explicații dintr-o singură linie de log:

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

Primul rând este un mecanism de securitate care își face treaba, iar al doilea este un dispozitiv intermediar care uită starea. Confundarea lor duce fie la slăbirea reînnoirii, fie la urmărirea unei reguli de firewall care nu a fost niciodată implicată.

Ocupat versus inactiv îți spune care jumătate

Fă o comparație controlată cu trafic continuu, cum ar fi un flux lung către un host din interiorul tunelului, și urmărește dacă intervalul se schimbă. Dacă căderea dispare în timp ce curg datele, cronometrul se bazează pe inactivitate.

Dacă supraviețuiește traficului continuu, cauza aparține reînnoirii, lease-ului sau politicii. Acel singur test elimină jumătate dintre candidați în aproximativ o oră de observație și nu costă nimic în afară de atenție.

Menține rețeaua de acces neschimbată în timpul testului. Trecerea între Wi-Fi și Ethernet la mijlocul comparației introduce exact evenimentul de interfață pe care încerci să îl distingi de un cronometru.

Potrivește linia de log cu limita

Citește logurile clientului și serverului din jurul momentului înregistrat, nu fișierul întreg. O reînnoire arată negociere; o expirare de inactivitate nu arată nimic până la următorul pachet; o schimbare de lease arată lucru pe adresă; o limită de politică arată de obicei o deconectare administrativă curată.

Aceste comenzi extrag fereastra relevantă din fiecare sursă:

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

Dacă cele trei surse sunt de acord asupra marcajului de timp, cunoști proprietarul cronometrului. Dacă doar logul clientului conține ceva, probabil serverul nu este cel care încheie sesiunea.

Repară etapa, nu pictograma

Fiecare proprietar are o singură reparație acceptată. O defecțiune de reînnoire necesită propuneri compatibile la ambele capete. O expirare de inactivitate necesită un keepalive sau o așteptare de inactivitate mai scurtă, în limitele permise de traseu. Un eveniment de lease necesită corectarea setărilor interfeței sau ale alimentării. O limită de cont este o decizie de politică, nu un bug.

Dezactivarea reînnoirii sau a autentificării pentru a păstra pictograma verde schimbă o cădere vizibilă pe o slăbiciune invizibilă și te lasă incapabil să spui când tunelul a negociat ultima dată chei noi. Retestează durata originală după aceea și păstrează marcajele de timp, astfel încât următorul eveniment să poată fi comparat cu acesta în loc să o iei de la capăt.

Articole similare