Cum să testezi comutatorul VPN fără conturi reale
Fă un test al comutatorului cu o pagină-momeală și un profil de rezervă: acoperă fiecare tip de întrerupere, citește codurile de ieșire curl și separă o blocare reală de o defecțiune DNS.
Nu ai nevoie de un cont real ca să afli dacă un comutator de blocare ține; tocmai contul este cel expus de test. Verificarea creează o fereastră scurtă în care traficul poate sau nu poate ieși în afara tunelului, așa că încărcătura trebuie să fie ceva ce poți pierde. Acum fac asta cu o pagină-momeală și un profil de browser de rezervă, iar răspunsul e mai clar decât în rutina cu browser și webmail pe care o foloseam înainte. În continuare urmez aceeași ordine pe care o arată clientul: setarea, destinația, tranziția și apoi dovada.
Testul răspunde la o singură întrebare îngustă: în timpul acestei tranziții, poate această aplicație să ajungă la rețeaua din afara tunelului? nu spune nimic despre dacă restul politicii este rezonabil. Ține domeniul atât de îngust și rezultatul merită notat.
Găsește comutatorul și domeniul lui în client
Deschide clientul și găsește setarea de blocare înainte de a schimba orice stare a rețelei. Producătorii o numesc diferit: comutator de blocare, mod de blocare, lacăt de rețea, blocarea traficului din afara tunelului. Eticheta spune mai puțin decât opțiunile din interior. Contează dacă blocarea se aplică mereu sau doar când aplicația decide că tunelul tocmai a eșuat, și dacă acoperă toate aplicațiile sau o listă selectată.
Apoi listează tranzițiile pe care clientul tău chiar le poate executa. O deconectare inițiată de utilizator, ieșirea din aplicație și pierderea contactului cu serverul sunt trei căi de cod diferite în majoritatea clienților, și nu împart o singură politică de blocare. Unii eliberează blocarea când aplicația se închide. Alții lasă regulile de filtrare până când ceva le elimină. Citește referința de setări a producătorului pentru versiunea pe care o rulezi în loc să presupui, apoi notează pe care dintre cele trei îl testezi.
Notează și profilul: protocolul, familiile de adrese și dacă tunelul divizat este activat. Afirmația că acoperă întregul dispozitiv nu are sens dacă profilul exclude intenționat câteva aplicații, iar o excludere pe care ai configurat-o tu nu este o scurgere. Referința de setări a OpenVPN Connect este genul de pagină care numește ce comutator schimbă ce comportament, deși etichetele diferă de la client la client.
Alege o destinație-momeală care funcționează și fără tunel
Momeala are nevoie de două proprietăți, iar omiterea oricăreia produce un rezultat de necitit. Trebuie să fie accesibilă direct când tunelul este jos și blocarea este oprită, altfel faptul că a încetat să răspundă poate însemna doar că gazda a dispărut. Și nu trebuie să ceară autentificare, cookie sau plată, ca o scurgere să coste o linie de jurnal în loc de o sesiune.
O pagină statică pe o gazdă pe care o controlezi este alegerea cea mai curată. O mașină virtuală de rezervă cu un server HTTP simplu este aproape la fel de bună, iar o pagină publică de verificare a conectivității merge dacă accepți că disponibilitatea ei este în afara controlului tău. Notează adresa, portul, familia de adrese și dacă cererea are nevoie de căutarea numelui, pentru că fiecare dintre ele devine o variabilă pe care poate va trebui să o izolezi mai târziu.
Stabilește linia de bază înainte de a atinge comutatorul. Cu tunelul sus, momeala trebuie să răspundă prin tunel, ceea ce dovedește că ruta conform politicii funcționează. Cu tunelul jos și blocarea oprită, trebuie să răspundă direct, ceea ce dovedește că destinația este vie. Abia atunci un eșec în starea blocată îți spune ceva.
Execută tranzițiile într-o ordine fixă
Ia tranzițiile una câte una și dă fiecăreia câteva secunde să se așeze, pentru că clienții deseori demolează și reconstruiesc regulile în acel interval. Aceeași verificare scurtă de fiecare dată face observațiile comparabile:
curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"| Transition | Expected with the block on | Failure signature |
|---|---|---|
| Manual disconnect | Decoy stops answering within seconds | Decoy still returns 200 |
| Server or path failure | Blocked, with no exemption for the old endpoint | Direct access during the gap |
| Quit the app | Client-dependent; record what happens | Block disappears with the process |
| Wi-Fi to Ethernet | Block holds until the tunnel returns | Traffic flows mid-change |
Rândul cu ieșirea din aplicație merită o rulare proprie, chiar dacă nu închizi niciodată clientul în uzul normal. Dacă blocarea se eliberează la ieșire, un crash sau o actualizare forțată îți dau aceeași expunere, iar asta este un fapt despre implementare, nu despre răbdarea ta. Pe Windows, sondele echivalente sunt Resolve-DnsName decoy.example și curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.
Separă o blocare de un resolver stricat
O pagină care nu se încarcă are mai multe cauze, și doar una dintre ele este comutatorul care funcționează. Dacă numele nu se rezolvă, ai aflat că DNS este blocat sau stricat, nu că este blocată calea de date. Testează și o adresă literală, ca răspunsul să nu depindă deloc de rezolvare.
Codurile de ieșire ale curl separă aceste cazuri. 6 este o eroare de rezolvare a numelui, 7 înseamnă că conexiunea a fost refuzată, 28 este un timeout. O rută blocată apare de obicei ca timeout sau refuz către o adresă literală, în timp ce o blocare doar a DNS lasă 6 și ascunde tot restul. O pagină din cache sau un portal captiv înșală ochiul, de aceea dovada este codul de ieșire, nu ecranul.
Repetă sonda pe IPv6 cu o adresă literală. O blocare care acoperă IPv4 și ignoră IPv6 este destul de comună ca să merite o linie proprie în note, iar un client care dezactivează IPv6 în afara tunelului ar trebui să eșueze curat pe ambele familii.
Notează domeniul pe care îl acoperă rezultatul
Când tunelul revine, confirmă recuperarea: momeala răspunde prin tunel, resolverul returnează răspunsuri, iar politica stă unde ai lăsat-o. Apoi anulează experimentele. O regulă temporară de firewall, o rută de depanare sau un profil de test lăsate pe loc vor încurca următoarea rulare și pot supraviețui aplicației.
O singură trecere acoperă o versiune a clientului, un profil, o tranziție și o familie de adrese. Notează cele patru împreună cu rezultatul:
- Versiunea clientului și platforma, și dacă setarea este pe profil sau globală.
- Profil, protocol și orice excluderi de tunel divizat.
- Tranziția testată și cum ai declanșat-o.
- Familiile de adrese și DNS, cu codurile de ieșire curl pentru starea blocată și neblocată.
Dacă vreo linie este goală, testul nu este terminat. Roaming înseamnă repetarea rândului cu schimbarea de rețea. O repornire nesupravegheată înseamnă verificarea faptului că regulile revin, iar asta este o întrebare despre ordinea de restaurare, nu despre comutator. Repetă secvența după o actualizare a clientului, pentru că întrerupătoarele se schimbă rar, în timp ce comportamentul din spatele lor se schimbă. Ține momeala la îndemână: nu e nimic de rotit, iar următoarea verificare durează cinci minute.