Îngheț de două secunde: a fost VPN-ul sau Wi-Fi-ul?
O oprire de două secunde și o sesiune VPN nouă sunt evenimente diferite. Puneți calea de acces și tunelul pe axe de timp separate înainte de a schimba un temporizator.
Un îngheț de două secunde care se remediază singur arată la fel, fie că tunelul a renegociat, fie că radioul s-a împiedicat. Este posibil și să nu fi căzut nimic deloc, iar această posibilitate merită testată prima. O rafală scurtă de pierderi, o renegociere și o blocare a aplicației se simt la fel pentru persoana de la tastatură. Doar unul dintre cele trei cazuri se rezolvă modificând configurația tunelului.
Două înregistrări, nu una
Notați ce s-a întâmplat cu conexiunea de dedesubt și, separat, ce a făcut tunelul însuși. Apoi puneți pauza aplicației în fața ambelor înregistrări. Sunt serii independente de evenimente care uneori coincid, iar a le numi pe toate trei deconectare presupune răspunsul încă de la început.
Un monitor care testează o dată pe minut nu poate vedea o întrerupere de două secunde. A raporta acea zi ca sănătoasă este corect tehnic și inutil practic. Puneți intervalul de eșantionare lângă fiecare rezultat pe care îl citați.
Ce a făcut legătura de acces cât timp aplicația era înghețată
Intervalul de eșantionare și limita de timp stabilesc ce ar fi putut observa monitorul, așa că notați-le pe amândouă lângă rezultat. Absența înregistrată a întreruperilor înseamnă puțin când instrumentul eșantionează la fiecare șaizeci de secunde. Apoi verificați trei locuri cu marcaje de timp: routerul local, un host extern aprobat atins pe calea simplă și o resursă din spatele tunelului.
Confirmați mai întâi rutele, pentru că o țintă publică poate fi ea însăși rutată prin tunel și atunci măsoară tunelul în locul căii de acces. Dovezile care datează cu adevărat întreruperea stau un strat mai jos: evenimente de legătură pe router, înregistrări de resincronizare pe modem și o adresă WAN care s-a schimbat. Un contor cumulativ de erori vă spune că ceva a mers prost, niciodată când. Corelați acele înregistrări cu fereastra incidentului în loc să le citiți izolat.
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address showUn contor care a crescut ieri nu explică nimic despre un îngheț de dimineață. Limitați corelația la fereastra raportată de utilizator.
Căutați înregistrarea de repornire
Un datagram UDP pierdut nu face, de la sine, ca Community OpenVPN să înceapă o nouă negociere TLS. Comportamentul de repornire urmează ping-restart, iar valoarea în vigoare poate fi fost impusă de server; manualul pentru 2.6 definește acele temporizatoare. Livrarea se întrerupe pentru o clipă, pragul nu este niciodată depășit, iar jurnalul rămâne gol. De aceea căutați în jurnal în jurul pauzei o linie de repornire, o conexiune nouă sau un identificator de sesiune modificat. Dacă niciunul dintre cele trei nu apare, tunelul probabil nu a făcut nimic, iar temporizatorul nu a fost niciodată problema.
Scurtarea fiecărui keepalive face detecția să pară mai rapidă și mută linia la care o mică poticnire devine reconectare. Fiecare reconectare costă o rundă de autentificare și reinstalarea rutelor. Lungirea temporizatorului nu cumpără nimic în afară de o fereastră mai lungă în care o cale moartă încă pare vie. Ambele sunt decizii de reglaj cu un preț, nu îmbunătățiri gratuite.
Un eveniment absent este și el o dovadă, și este exact genul pe care oamenii îl sar pentru că nimic din jurnal nu atrage atenția asupra lui. Notați căutarea pe care ați făcut-o, nu doar rezultatul.
Lăsați comparația să decidă ce trebuie reparat
Cu ambele înregistrări una lângă alta, atribuirea se scrie de obicei singură. Un eveniment de legătură pe router pe ambele căi înseamnă că subiectul este conexiunea de acces. Un tunel liniștit și o cale simplă utilizabilă înseamnă că subiectul este negocierea.
| 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 |
Fiecare rând este un indiciu, nu un verdict: punctele finale scad prioritatea ICMP, iar două destinații nu împart neapărat o cale. Țineți ceasurile clientului, ale gateway-ului și ale aplicației aliniate pentru ca comparația să fie măcar posibilă. Un rând care se potrivește în două coloane are nevoie de încă o observație, nu de o decizie.
Un raport care trece de verificare răspunde la patru lucruri: cât a durat înghețul, ce căi au continuat să răspundă, ce a înregistrat tunelul în acea secundă și cât de des eșantionează monitorul. Aceste patru fapte îi permit următorului cititor să reproducă observația în loc să se bazeze pe un rezumat. Un procent de disponibilitate ascunde exact intervalul care vă interesează, iar sintagma "VPN-ul a căzut" la fel.