Comutator de siguranță VPN: ce trafic blochează și când
Reconectarea reface un tunel; comutatorul decide ce se întâmplă cât timp acesta lipsește. Testați separat pierderea conexiunii, deconectarea manuală, ieșirea din aplicație și schimbarea rețelei.
Două funcții sunt descrise cu același cuvânt și fac lucruri diferite. Reconectarea automată încearcă să readucă tunelul, și poate reuși într-o secundă în timp ce cererile eșuează în acel interval. Comutatorul decide ce se întâmplă cu traficul în acel interval. Citirea unui client ca și cum cele două ar fi o singură setare duce la oameni care ajung să aibă încredere într-o pictogramă în locul unei politici.
Blocarea și reconectarea sunt decizii separate
Un client blochează doar când pierderea este neașteptată, apoi se reconectează și ridică blocajul. Altul ține un blocaj la nivel de sistem până când cineva schimbă o setare manual, iar al treilea tratează deconectarea deliberată ca permisiune de a restabili accesul obișnuit. Sunt trei comportamente diferite, iar documentația furnizorului spune pe care îl implementează versiunea dumneavoastră.
Importul unui profil nu decide nimic în această privință. Același profil de server se încarcă în doi clienți cu comportamente de blocare opuse, pentru că profilul transportă setări, nu o promisiune. De aceea o casetă de pe desktop și un comutator de pe telefon cu etichete similare pot implementa reguli diferite. Citiți descrierea de lângă controlul din platforma dumneavoastră și apoi testați ce face.
Același profil se comportă diferit în doi clienți
Setările aplicației OpenVPN Connect descriu un mod de tunel care reține traficul obișnuit doar cât timp clientul raportează o stare de pauză sau de reconectare, ceea ce este mai îngust decât o promisiune generală despre fiecare eveniment pe fiecare platformă. Citiți stările enumerate, nu numele produsului. O descriere scrisă pentru o versiune de client nu se transferă la clientul altui furnizor.
Android afișează același cuvânt pentru două controale, pentru că VPN-ul mereu activ și blocarea conexiunilor fără VPN sunt documentate separat. Un client de desktop cu o casetă cu nume similar poate implementa ceva mai îngust sau mai larg decât oricare dintre ele. Considerați o etichetă comună în două meniuri o coincidență până când ambele descrieri sunt citite. Dispozitivele administrate adaugă un al treilea strat, pentru că un profil de dispozitiv poate impune o setare pe care utilizatorul nu o vede și nu o poate anula.
Setări de platformă asemănătoare nu sunt echivalente
Comparați controlul pe care îl vedeți cu politica ce se aplică de fapt. Pe un dispozitiv administrat, comutatorul vizibil poate fi gri sau poate fi activat în timp ce un profil de nivel superior impune contrariul. Cereți politica efectivă, nu pe cea locală, și obțineți răspunsul în scris.
Notați ce susține fiecare strat înainte de a testa ceva, pentru că cele două nu sunt de acord adesea, iar nepotrivirea se pierde ușor odată ce încep testele. Un dispozitiv care blochează corect în timpul unui test poate bloca dintr-un motiv pe care nimeni nu l-a documentat.
Rulați un eveniment o dată și notați codul
Testați un eveniment pe rulare, cu o cerere inofensivă, și faceți din fiecare încercare o cerere nouă, nu o pagină care poate fi deja în cache. Comenzile de mai jos coboară tunelul, cer o pagină și arată dacă interfața a revenit.
ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0
Tabelul asociază fiecare acțiune observației care contează și dovezii care merită păstrată. O cerere care eșuează în intervalul de timp arată că blocajul a intrat în acțiune; o cerere care trece arată că traficul a găsit altă cale, care poate fi o rută exclusă și nu un blocaj dezactivat. Repetați întregul set după o actualizare software semnificativă sau o schimbare a politicii de rutare, pentru că oricare dintre ele poate schimba ramura fără ca vreo setare vizibilă să se miște. La final doriți un comportament de eșec previzibil, nu o pictogramă liniștitoare.
| What I do | What I watch | Evidence to keep |
|---|---|---|
| Bring the tunnel down by hand | Whether a fresh request fails at once | The HTTP code and the client state at that second |
| Choose Disconnect in the client | Whether ordinary access returns on purpose | The same request succeeding with no tunnel up |
| Quit the app, then reboot | Whether the block outlives the client | A request made from a clean boot |
| Move from Wi-Fi to cellular | Whether DNS and IPv6 follow the policy | The resolver answer, the route table and the code again |
Excepții, portaluri pentru oaspeți și ce nu poate un blocaj
Accesul la rețeaua locală este excepția obișnuită și schimbă amploarea promisiunii. Un client poate ajunge la o imprimantă din aceeași subrețea blocând tot restul, ceea ce este rezonabil acasă și discutabil într-o rețea pentru oaspeți. Decideți dacă doriți această excepție înainte ca un incident să o descopere pentru dumneavoastră.
Un blocaj strict face și autentificarea în portalul unei rețele pentru oaspeți incomodă, pentru că portalul este exact traficul direct pe care blocajul există să îl oprească. Învățați metoda acceptată de autorizare a rețelei și apoi restabiliți politica în mod deliberat, în loc să opriți controale până se încarcă o pagină. Păstrați răspunsul resolverului și tabela de rutare în aceeași notă, ca mai jos. Ce un comutator nu poate face este să facă serviciul anonim, pentru că blocarea traficului din afara tunelului nu spune nimic despre ce se întâmplă în interiorul lui.
resolvectl query example.com
ss -tunp | grep -v tun0