Vreți să știți dacă tunelul supraviețuiește unei suspendări a laptopului, unei plimbări între puncte de acces, sau unei ore de apeluri, și preferați să nu dați nimănui un jurnal cu tot ce citiți în timp ce aflați asta. Trei lucruri răspund la asta: o sondă fixă, aceleași patru fapte eșantionate după un program și evenimentul care le-a schimbat, notat. Zece minute din asta bat o după-amiază petrecută privind o pagină care nu se încarcă. Jurnalul care rămâne este și destul de scurt pentru a fi atașat la un tichet fără a ascunde jumătate din el.

Decideți ce trebuie să însemne stabil

„VPN-ul a căzut” sunt patru defecțiuni diferite într-un singur cuvânt. Peerul poate pierde strângerea de mână, ruta poate reveni la gateway-ul local, rezolvarea numelor poate merge la un server care nu răspunde niciodată prin tunel, sau toate acestea pot fi sănătoase în timp ce o aplicație încă eșuează. Decideți care se potrivește simptomului vostru înainte de a colecta ceva, pentru că fiecare cere o altă sondă. Apoi alegeți un interval pe care îl puteți ține: o eșantionare la fiecare treizeci de secunde timp de zece minute prinde un roaming fără a transforma testul în sarcină de lucru.

Dacă reclamația este un apel care îngheață când mergeți în bucătărie, proprietatea de care aveți nevoie este dacă o cerere nouă se finalizează după roaming. Asta se verifică într-o singură linie și nu înregistrează nicio navigare.

Fixați o sondă inofensivă

Alegeți o destinație pe care aveți voie să o interogați și care nu este legată de conturile voastre: un host de documentație, un punct final de stare intern sau chiar gateway-ul tunelului. Faceți operația repetabilă, de exemplu curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://example.com/, care tipărește o linie pe încercare. Păstrați acel format de ieșire fix pe toată rularea. Un cod de stare și o durată colectate la fel de două ori sunt ceea ce face două rulări comparabile.

Rezistați site-ului pe care vă bazați cu adevărat. O pagină de bancă sau de webmail aduce în măsurătoare trackere, redirecționări și conținut personal și tipărește identificatori de sesiune în tot ce lipiți mai târziu într-un tichet. Folosiți aceeași destinație pe toată investigația și notați-o lângă interval.

Eșantionați cele patru fapte

Starea peerului, ruta, resolverul și o cerere nouă sunt cele patru observații, iar fiecare are o sursă ieftină. În WireGuard, wg show wg0 latest-handshakes dă marca de timp a peerului, iar ip route get 1.1.1.1 arată ce interfață ar folosi kernelul. În OpenVPN aceeași stare se află în fișierul de stare scris de --status /run/openvpn/status 10 sau în spatele lui state pe interfața de administrare. Un client Windows rămâne în PowerShell cu Get-NetAdapter și Resolve-DnsName.

Puneți-le în buclă într-un singur terminal astfel încât fiecare linie să poarte o marcă de timp: for i in $(seq 1 20); do date -Is; wg show wg0 latest-handshakes; ip route get 1.1.1.1; sleep 30; done. Acea buclă acoperă trei dintre cele șase câmpuri ale jurnalului; versiunea clientului se trece o dată sus, iar marca de timp a evenimentului se adaugă când evenimentul are loc.

Resolverul este faptul pe care oamenii îl sar, iar dig +short îl ascunde, pentru că acea formă tipărește doar răspunsul. Întrebați serverul în mod explicit cu dig example.com | grep SERVER:, sau folosiți nslookup example.com acolo unde dig nu este instalat, care tipărește adresa serverului către care a mers interogarea. O strângere de mână veche pe un tunel inactiv nu este nici ea automat o defecțiune, întrucât WireGuard schimbă cheile doar când există trafic de protejat.

Declanșați evenimentul, nu o scurgere

Luați cinci minute liniștite ca linie de bază înainte de evenimentul care vă interesează, fie că este închiderea capacului, mersul la alt punct de acces sau trecerea la hotspotul unui telefon. Notați ora la care l-ați declanșat, ca eșantioanele de pe ambele părți să poată fi aliniate.

Fără acea marcă de timp jurnalul arată un gol și nimeni nu poate spune dacă l-a închis clientul sau rețeaua. Două rulări cu evenimentul în locuri diferite valorează mai mult decât zece fără el. Folosiți comenzile proprii ale clientului de deconectare și reconectare. Nu dezactivați kill switch-ul și nu împingeți traficul în afara tunelului ca să vedeți ce se întâmplă, pentru că pe un laptop administrat aceasta este o încălcare de politică, iar pe mașina proprie creează exact expunerea pe care o testați.

Țineți un jurnal destul de mic ca să îl terminați

Șase câmpuri pe eșantion: ora, versiunea clientului, punctul final, rețeaua de acces, evenimentul, rezultatul. Lăsați afară adresele web, încărcăturile utile, tokenurile și orice poartă un identificator de sesiune, pentru că jurnalul este dovadă despre tunel și nimic altceva. Țineți-l lângă buclă, ca următoarea persoană să îl poată rula din nou fără să întrebe ce înseamnă coloanele.

După o schimbare, repetați testul cu aceeași sondă și același interval; dacă schimbați destinația și versiunea clientului împreună, rezultatul nu aparține niciuneia. O rulare curată de zece minute este dovadă pentru acele condiții și acea destinație, nu o promisiune despre rețeaua hotelului luna viitoare. Păstrați scriptul și șablonul de jurnal acolo unde le veți găsi. Limitările documentate ale WireGuard merită citite înainte de a atribui o întrerupere protocolului.

Articole similare