Interruptor por aplicación fronte ao bloqueo de todo o dispositivo: que cambia
Decida polo conxunto protexido, non pola etiqueta: que se detén para as aplicacións excluídas, os axudantes en segundo plano e as conexións novas, e como probar cada caso.
Un interruptor por aplicación soa como a opción prudente: só o cliente de traballo perde a súa rede cando cae o túnel, e todo o demais segue funcionando. Logo alguén nota que o navegador persoal cargou unha páxina de todos os xeitos, que o axudante de sincronización do mesmo paquete seguía reintentando e que un nome na caché seguía resolvéndose a un enderezo que nunca tocou o túnel. A etiqueta da función e o conxunto de conexións que realmente protexe son dúas cousas distintas. Determine primeiro o conxunto protexido, porque ese conxunto decide se a aplicación por aplicación ou o bloqueo de todo o dispositivo é a descrición honesta.
Comece polo conxunto, non pola etiqueta
Unha política por aplicación protexe aplicacións seleccionadas. Un bloqueo de dispositivo apunta a un límite de rede máis amplo, normalmente con excepcións documentadas para impresión local, tráfico de xestión ou portais cativos. Ningunha das dúas etiquetas está completa ata que poida responder tres preguntas: que ocorre coas aplicacións excluídas, que ocorre cos axudantes que esas aplicacións inician e que ocorre coas conexións abertas mentres a protección non está dispoñible.
Escriba esas respostas antes de tocar calquera axuste do cliente. Se o requisito é "este cliente de nóminas nunca debe falar con internet fóra do túnel, e o meu navegador si pode", o conxunto é pequeno e a aplicación por aplicación encaixa. Se o requisito é "nada neste dispositivo chega a internet sen protección, agás o servizo de actualizacións", ningunha política por aplicación o producirá, porque as aplicacións que non nomeou son o problema.
A aplicación por aplicación coincide con identificadores, non con nomes de programa
Android expón a VPN por aplicación mediante paquetes, e a súa documentación de VpnService describe como interactúa iso co funcionamento sempre activo e o bloqueo. iOS configura a VPN por aplicación mediante un perfil de xestión e coincide por aplicación ou por dominio. Windows e Linux non teñen ningunha ruta por proceso, así que a mesma idea aproxímase cunha regra de devasas limitada a un programa ou cunha regra que coincide co usuario propietario.
O límite é o identificador, e os identificadores son fáciles de esquivar. Unha aplicación que entrega un URL ao navegador do sistema, ou abre un documento nun visor, pasa a un proceso que a súa política nunca nomeou. Unha opción de terminar ao caer tampouco é un filtro de paquetes: mata a aplicación que configurou, mentres un proceso fillo, un traballador de cola ou unha lapela do navegador poden manter vivo un socket existente.
O bloqueo cobre o que unha política por aplicación non pode ver
O bloqueo de todo o dispositivo elimina a elección. Cada paquete saínte que non pertence ao túnel descártase, incluído o tráfico de procesos que a súa política de aplicacións nunca coñeceu. En Android iso é VPN sempre activa combinada co axuste de bloquear conexións, e a aplicación ocorre no sistema, non na xanela do cliente. Nun escritorio é unha regra de devasas persistente ou unha ruta predeterminada apuntada a unha pasarela inalcanzable.
O custo é que todo o demais se detén, así que as excepcións pasan a formar parte do deseño en lugar de ser un engadido. Impresoras locais, descuberta de servizos, inicios de sesión en portais cativos, axentes de xestión e actualizacións do sistema operativo necesitan cada un un burato documentado, porque cada un é un camiño que permanece aberto cando o túnel está caído. O bloqueo só é tan forte como a entrada máis curta desa lista.
DNS, IPv6 e os axudantes en segundo plano agochan as fugas
Que unha aplicación protexida non resolva un nome non demostra que as respostas na caché ou o tráfico IP directo estean bloqueados. Se o resolutor segue sendo alcanzable fóra do túnel, o nome resólvese e a conexión falla, o que parece un interruptor que funciona e non o é. Peor aínda, un rexistro na caché pode apuntar a un enderezo que o túnel non transporta, así que a conexión sae directamente mentres a aplicación informa dun erro de VPN.
IPv6 necesita a súa propia regra en cada plataforma que o executa, porque unha regra de descarte para v4 non cobre unha ruta v6. No móbil, un axuste de DNS privado pode mover a resolución a unha canle cifrada que a política do dispositivo non inspecciona. E os axudantes en segundo plano son o culpable habitual no escritorio: un proceso de actualización ou de bandexa de sincronización arrinca antes que o cliente VPN e mantén a súa propia conexión, así que nunca ve a ruta cambiada.
Probe tres aplicacións e dúas transicións
| 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 |
Execute cada fila dúas veces, unha cun nome de host e outra cun enderezo literal, e outra máis por IPv6 se a rede o ofrece. Un aprobado significa que a aplicación incluída se detivo, a excluída comportouse como vostede escribiu e o axudante non se escapou. Anote o comportamento directo que decidiu que era aceptable, para que o seguinte administrador distinga unha excepción deliberada dun fallo.
Despois describa o resultado nunha frase que nomee as aplicacións e as condicións, por exemplo: o cliente de nóminas non ten ruta fóra do túnel, o navegador é directo por deseño e todo o demais detense cando o túnel está caído. Se esa frase é difícil de escribir, a política segue a ser dúas políticas que loitan entre si.