Kill switch pe aplicație versus blocarea întregului dispozitiv: ce se schimbă

Un kill switch pe aplicație sună ca alegerea prudentă: doar clientul de lucru își pierde rețeaua când tunelul cade, iar tot restul continuă să funcționeze. Apoi cineva observă că browserul personal a încărcat totuși o pagină, că ajutorul de sincronizare livrat cu același pachet continua să încerce și că un nume din cache se rezolva în continuare la o adresă care nu a atins niciodată tunelul. Eticheta de pe funcție și mulțimea de conexiuni pe care o protejează de fapt sunt două lucruri diferite. Stabiliți mai întâi mulțimea protejată, pentru că ea decide dacă aplicarea pe aplicație sau blocarea întregului dispozitiv este descrierea onestă.

Începeți cu mulțimea, nu cu eticheta

O politică pe aplicație protejează aplicațiile selectate. O blocare de dispozitiv vizează o frontieră de rețea mai largă, de obicei cu excepții documentate pentru imprimarea locală, traficul de administrare sau portalurile captive. Niciuna dintre etichete nu este completă până când nu puteți răspunde la trei întrebări: ce se întâmplă cu aplicațiile excluse, ce se întâmplă cu ajutoarele pe care aceste aplicații le pornesc și ce se întâmplă cu conexiunile deschise cât timp protecția nu este disponibilă.

Scrieți aceste răspunsuri înainte de a atinge vreo setare a clientului. Dacă cerința este "acest client de salarizare nu trebuie să vorbească niciodată cu internetul în afara tunelului, iar browserul meu poate", mulțimea este mică și aplicarea pe aplicație se potrivește. Dacă cerința este "nimic de pe acest dispozitiv nu ajunge la internet fără protecție, cu excepția serviciului de actualizare", nicio politică pe aplicație nu o va produce, pentru că aplicațiile pe care nu le-ați numit sunt problema.

Aplicarea pe aplicație potrivește identificatori, nu nume de programe

Android expune VPN pe aplicație prin pachete, iar documentația VpnService descrie cum interacționează aceasta cu funcționarea permanentă și blocarea. iOS configurează VPN pe aplicație printr-un profil de administrare și potrivește după aplicație sau după domeniu. Windows și Linux nu au deloc rută pe proces, așa că aceeași idee este aproximată cu o regulă de firewall limitată la un program sau cu o regulă care potrivește utilizatorul proprietar.

Limita este identificatorul, iar identificatorii sunt ușor de ocolit. O aplicație care predă un URL browserului sistemului sau deschide un document într-un vizualizator trece într-un proces pe care politica dumneavoastră nu l-a numit niciodată. O opțiune de terminare la cădere nu este nici filtru de pachete: ucide aplicația pe care ați configurat-o, în timp ce un proces copil, un lucrător de coadă sau un tab de browser pot ține în viață un socket existent.

Blocarea acoperă ce o politică pe aplicație nu poate vedea

Blocarea întregului dispozitiv elimină alegerea. Fiecare pachet de ieșire care nu aparține tunelului este aruncat, inclusiv traficul de la procese despre care politica aplicațiilor nu a știut niciodată. Pe Android aceasta este VPN-ul permanent combinat cu setarea de blocare a conexiunilor, iar aplicarea are loc în sistem, nu în fereastra clientului. Pe desktop este o regulă de firewall persistentă sau o rută implicită îndreptată spre o poartă inaccesibilă.

Costul este că tot restul se oprește, așa că excepțiile devin parte din proiectare, nu un gând ulterior. Imprimantele locale, descoperirea serviciilor, autentificarea în portalurile captive, agenții de administrare și actualizările sistemului de operare au nevoie fiecare de o gaură documentată, pentru că fiecare este o cale care rămâne deschisă când tunelul este căzut. Blocarea este doar atât de puternică pe cât este cea mai scurtă intrare din acea listă.

DNS, IPv6 și ajutoarele din fundal ascund scurgerile

Faptul că o aplicație protejată nu reușește să rezolve un nume nu dovedește că răspunsurile din cache sau traficul IP direct sunt blocate. Dacă resolverul este încă accesibil în afara tunelului, numele se rezolvă și conexiunea eșuează, ceea ce arată ca un kill switch funcțional și nu este. Mai rău, o înregistrare din cache poate indica o adresă pe care tunelul nu o transportă, așa că conexiunea iese direct în timp ce aplicația raportează o eroare VPN.

IPv6 are nevoie de propria regulă pe fiecare platformă care îl rulează, pentru că o regulă de aruncare pentru v4 nu acoperă o rută v6. Pe mobil, o setare de DNS privat poate muta rezolvarea într-un canal criptat pe care politica dispozitivului nu îl inspectează. Iar ajutoarele din fundal sunt vinovatul obișnuit pe desktop: un proces de actualizare sau de sincronizare din tray pornește înaintea clientului VPN și își ține propria conexiune, așa că nu vede niciodată ruta schimbată.

Testați trei aplicații și două tranziții

Rulați fiecare rând de două ori, o dată cu un nume de gazdă și o dată cu o adresă literală, și încă o dată prin IPv6 dacă rețeaua oferă asta. O reușită înseamnă că aplicația inclusă s-a oprit, cea exclusă s-a comportat cum ați scris și ajutorul nu a scăpat. Notați comportamentul direct pe care l-ați considerat acceptabil, ca următorul administrator să poată distinge o excepție deliberată de o defecțiune.

Apoi descrieți rezultatul într-o singură frază care numește aplicațiile și condițiile, de exemplu: clientul de salarizare nu are rută în afara tunelului, browserul este direct prin proiectare, iar tot restul se oprește când tunelul este căzut. Dacă acea frază este greu de scris, politica este încă două politici care se luptă între ele.