Interruptor per aplicació versus bloqueig de tot el dispositiu: què canvia
Decidiu pel conjunt protegit, no per l'etiqueta: què s'atura per a les aplicacions excloses, els auxiliars en segon pla i les connexions noves, i com provar cada cas.
Un interruptor per aplicació sona com l'opció prudent: només el client de feina perd la xarxa quan cau el túnel, i tota la resta continua funcionant. Després algú s'adona que el navegador personal encara va carregar una pàgina, que l'auxiliar de sincronització del mateix paquet continuava reintentant i que un nom en memòria cau encara es resolia a una adreça que no va tocar mai el túnel. L'etiqueta de la funció i el conjunt de connexions que realment protegeix són dues coses diferents. Determineu primer el conjunt protegit, perquè aquest conjunt decideix si l'aplicació per aplicació o el bloqueig de tot el dispositiu és la descripció honesta.
Comenceu pel conjunt, no per l'etiqueta
Una política per aplicació protegeix aplicacions seleccionades. Un bloqueig de dispositiu apunta a una frontera de xarxa més àmplia, normalment amb excepcions documentades per a impressió local, trànsit de gestió o portals captius. Cap de les dues etiquetes és completa fins que pugueu respondre tres preguntes: què passa amb les aplicacions excloses, què passa amb els auxiliars que aquestes aplicacions engeguen i què passa amb les connexions obertes mentre la protecció no està disponible.
Escriviu aquestes respostes abans de tocar cap paràmetre del client. Si el requisit és "aquest client de nòmines no ha de parlar mai amb internet fora del túnel, i el meu navegador sí que pot", el conjunt és petit i l'aplicació per aplicació encaixa. Si el requisit és "res d'aquest dispositiu arriba a internet sense protecció, excepte el servei d'actualitzacions", cap política per aplicació ho produirà, perquè les aplicacions que no heu nomenat són el problema.
L'aplicació per aplicació encaixa identificadors, no noms de programa
Android exposa el VPN per aplicació mitjançant paquets, i la seva documentació de VpnService descriu com interactua amb el funcionament sempre actiu i el bloqueig. iOS configura el VPN per aplicació mitjançant un perfil de gestió i encaixa per aplicació o per domini. Windows i Linux no tenen cap ruta per procés, així que la mateixa idea s'aproxima amb una regla de tallafoc limitada a un programa o amb una regla que encaixa amb l'usuari propietari.
La frontera és l'identificador, i els identificadors són fàcils d'esquivar. Una aplicació que lliura una URL al navegador del sistema, o obre un document en un visor, passa a un procés que la vostra política no va nomenar mai. Una opció de finalitzar en caure tampoc no és un filtre de paquets: mata l'aplicació que heu configurat, mentre un procés fill, un treballador de cua o una pestanya del navegador poden mantenir viu un sòcol existent.
El bloqueig cobreix el que una política per aplicació no pot veure
El bloqueig de tot el dispositiu elimina l'elecció. Cada paquet de sortida que no pertany al túnel es descarta, inclòs el trànsit de processos que la vostra política d'aplicacions no va conèixer mai. A Android això és VPN sempre actiu combinat amb el paràmetre de bloqueig de connexions, i l'aplicació passa al sistema, no a la finestra del client. En un escriptori és una regla de tallafoc persistent o una ruta per defecte apuntada a una passarel·la inabastable.
El cost és que tota la resta s'atura, així que les excepcions passen a formar part del disseny i no són un afegit posterior. Impressores locals, descobriment de serveis, inicis de sessió en portals captius, agents de gestió i actualitzacions del sistema operatiu necessiten cadascun un forat documentat, perquè cadascun és un camí que queda obert quan el túnel no funciona. El bloqueig és tan fort com l'entrada més curta d'aquesta llista.
DNS, IPv6 i auxiliars en segon pla amaguen les fuites
Que una aplicació protegida no resolgui un nom no demostra que les respostes en memòria cau o el trànsit directe per IP estiguin bloquejats. Si el resolutor encara és abastable fora del túnel, el nom es resol i la connexió falla, cosa que sembla un interruptor funcional i no ho és. Pitjor encara, un registre en memòria cau pot apuntar a una adreça que el túnel no transporta, de manera que la connexió surt directament mentre l'aplicació informa d'un error de VPN.
IPv6 necessita la seva pròpia regla a cada plataforma que l'executa, perquè una regla de descart per a v4 no cobreix una ruta v6. En mòbil, un paràmetre de DNS privat pot moure la resolució dins d'un canal xifrat que la política del dispositiu no inspecciona. I els auxiliars en segon pla són el culpable habitual en escriptori: un procés d'actualització o de safata de sincronització s'inicia abans que el client VPN i manté la seva pròpia connexió, així que no veu mai la ruta canviada.
Proveu tres aplicacions i dues transicions
| Test | What it proves |
|---|---|
| Included app, by name and by direct IP | the policy is applied, not just the resolver |
| Excluded app, same checks | the exclusion is intentional and documented |
| Helper or updater process | nothing inherited an older route |
| Tunnel drop, then Wi-Fi to cellular | the block survives the transition |
Executeu cada fila dues vegades, una amb un nom d'amfitrió i una amb una adreça literal, i una altra per IPv6 si la xarxa ho ofereix. Un èxit significa que l'aplicació inclosa es va aturar, l'exclosa es va comportar com vau escriure i l'auxiliar no es va escapar. Anoteu el comportament directe que vau decidir que era acceptable, perquè el proper administrador pugui distingir una excepció deliberada d'una fallada.
Després descriviu el resultat en una frase que nomeni les aplicacions i les condicions, per exemple: el client de nòmines no té cap ruta fora del túnel, el navegador és directe per disseny i tota la resta s'atura quan el túnel no funciona. Si aquesta frase és difícil d'escriure, la política encara són dues polítiques que lluiten entre si.