Întrerupătorul de siguranță este pornit, o aplicație este exclusă intenționat din tunel, iar cele două cerințe se contrazic acum. Unul spune că nimic nu poate ieși în afara tunelului, celălalt spune că acest program trebuie să meargă direct. Fiecare client rezolvă altfel acel conflict, iar pagina de setări explică rar care regulă câștigă. Scrieți politica pentru fiecare aplicație înainte de a avea încredere în orice etichetă.

Două politici, o singură mașină

Un întrerupător de siguranță este o promisiune despre eșec: când tunelul nu protejează traficul, traficul se oprește. Tunelul divizat este o promisiune despre selecție: aceste programe sau destinații folosesc tunelul, iar celelalte nu. A doua promisiune creează trafic despre care prima trebuie să decidă. Niciuna dintre promisiuni nu este greșită; pur și simplu le-au scris oameni diferiți pentru amenințări diferite.

Sunt posibile trei rezultate și doar unul este cel vizat de implementare. Aplicația exclusă poate rămâne directă în timpul unei întreruperi, ceea ce respectă divizarea și rupe întrerupătorul. Poate fi blocată împreună cu tot restul, ceea ce respectă întrerupătorul și rupe divizarea. Sau poate fi blocată doar uneori, în funcție de modul în care platforma evaluează regula după ce o interfață dispare. Ultimul caz este cel care generează tichete.

Scrieți lista de aplicații înainte de regulă

Enumerați programele care trebuie să folosească tunelul, pe cele care trebuie să meargă direct și numele sau destinațiile care nu trebuie să apară niciodată în niciuna dintre liste. Includeți separat comportamentul resolverului și partea IPv6, deoarece ambele pot urma o politică diferită de cea a traficului paginilor.

Regulile pe aplicație corespund de obicei unui executabil sau unui pachet, nu unui profil din interiorul lui. Un profil de browser, o fereastră privată și o extensie nu poartă o identitate de rețea proprie, așa că moștenesc ce a primit procesul. Un proces auxiliar lansat de acel browser poate să nu moștenească deloc aceeași regulă.

Sunt necesare două liste, nu una: ce trebuie să transporte tunelul și ce nu trebuie să călătorească în afara lui sub niciun motiv. O aplicație care apare pe ambele este un conflict de cerințe, nu un detaliu de implementare, și trebuie rezolvat înainte de configurarea clientului.

Ce face clientul în timpul unei întreruperi

Unele implementări blochează aplicațiile excluse în timpul unei întreruperi și le restaurează accesul la reconectare. Altele păstrează calea directă tot timpul, ceea ce este consecvent cu divizarea și mai slab ca proprietate de securitate. Blocarea la nivel de platformă poate anula complet selecția pe aplicație a clientului. Această diferență nu este cosmetică, pentru că decide dacă aplicația exclusă este o excepție de politică sau o gaură.

VPN-ul mereu activ al Android cu opțiunea de a bloca conexiunile fără VPN este cazul cel mai clar, pentru că platforma impune blocarea, nu clientul, iar pachetul exclus este blocat împreună cu tot restul cât timp tunelul este oprit. Un client desktop care aplică excepții pe aplicație în propriul driver lasă de obicei procesul exclus pe interfața fizică, pentru că nu a deținut niciodată traficul acelui proces. Ambele comportamente sunt de apărat și doar unul corespunde unei cerințe care spune că aplicația exclusă trebuie să rămână utilizabilă. Întrebați ce componentă impune regula înainte de a interpreta rezultatul.

Citiți comportamentul sistemului de operare din fața dumneavoastră, nu setarea cu același nume în altă parte. API-urile de impunere diferă, iar o casetă poate însemna lucruri strict diferite pe un desktop și pe un telefon. Contează și versiunea, pentru că controlul blocării s-a mutat între ecrane de-a lungul versiunilor Android, iar o listă de excepții pe partea clientului nu este același control ca o blocare de platformă.

Trei momente: tunel pornit, tunel oprit, reconectare

Folosiți cereri inofensive în trei momente: cât timp tunelul funcționează, în timpul eșecului care vă interesează și după reconectare. Un singur rezultat de browser nu poate stabili comportamentul aplicației excluse.

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com

Adresa de ieșire arată ce cale a fost urmată, iar testul explicit de interfață arată ce se întâmplă când tunelul este singura ieșire disponibilă. Notați rezultatul așteptat lângă fiecare linie înainte de a rula vreuna, altfel ieșirea va fi interpretată ulterior.

Dacă o aplicație exclusă rămâne fără conexiune, verificați prioritatea politicilor înainte de a adăuga o permisiune largă în firewall, pentru că acea corecție distruge distincția pe care o testați. Dacă rămâne directă, confirmați că a fost excepția documentată și nu o revenire accidentală. Pentru o cerință strictă pentru întregul dispozitiv, scurtați lista de excepții până când poate fi testată manual.

Articole similare