Interruptor por aplicação versus bloqueio de todo o dispositivo: o que muda
Decida pelo conjunto protegido, não pelo rótulo: o que para nas aplicações excluídas, nos auxiliares em segundo plano e nas novas ligações, e como testar cada caso.
Um interruptor por aplicação soa como a escolha cuidadosa: só o cliente de trabalho perde a rede quando o túnel cai, e tudo o resto continua a funcionar. Depois alguém repara que o navegador pessoal carregou uma página mesmo assim, que o auxiliar de sincronização do mesmo pacote continuava a tentar, e que um nome em cache ainda era resolvido para um endereço que nunca tocou no túnel. O rótulo da funcionalidade e o conjunto de ligações que ela realmente protege são duas coisas diferentes. Determine primeiro o conjunto protegido, porque é esse conjunto que decide se a aplicação por aplicação ou o bloqueio de todo o dispositivo é a descrição honesta.
Comece pelo conjunto, não pelo rótulo
Uma política por aplicação protege as aplicações selecionadas. Um bloqueio de dispositivo visa uma fronteira de rede mais ampla, normalmente com exceções documentadas para impressão local, tráfego de gestão ou portais cativos. Nenhum dos rótulos está completo até conseguir responder a três perguntas: o que acontece às aplicações excluídas, o que acontece aos auxiliares que essas aplicações iniciam e o que acontece às ligações abertas enquanto a proteção não está disponível.
Escreva essas respostas antes de tocar em qualquer definição do cliente. Se o requisito for "este cliente de salários nunca deve falar com a internet fora do túnel, e o meu navegador pode", o conjunto é pequeno e a aplicação por aplicação encaixa. Se o requisito for "nada neste dispositivo chega à internet sem proteção, exceto o serviço de atualizações", nenhuma política por aplicação o produzirá, porque as aplicações que não nomeou são o problema.
A aplicação por aplicação corresponde a identificadores, não a nomes de programas
O Android expõe a VPN por aplicação através de pacotes, e a sua documentação do VpnService descreve como isso interage com o funcionamento sempre ativo e o bloqueio. O iOS configura a VPN por aplicação através de um perfil de gestão e corresponde por aplicação ou por domínio. O Windows e o Linux não têm qualquer rota por processo, por isso a mesma ideia é aproximada com uma regra de firewall limitada a um programa ou com uma regra que corresponde ao utilizador proprietário.
O limite é o identificador, e os identificadores são fáceis de contornar. Uma aplicação que entrega um URL ao navegador do sistema, ou abre um documento num visualizador, passa para um processo que a sua política nunca nomeou. Uma opção de terminar ao cair também não é um filtro de pacotes: mata a aplicação que configurou, enquanto um processo filho, um trabalhador de fila ou um separador do navegador podem manter vivo um socket existente.
O bloqueio cobre o que uma política por aplicação não consegue ver
O bloqueio de todo o dispositivo retira a escolha. Cada pacote de saída que não pertence ao túnel é descartado, incluindo o tráfego de processos que a sua política de aplicações nunca conheceu. No Android isso é a VPN sempre ativa combinada com a definição de bloquear ligações, e a aplicação acontece no sistema, não na janela do cliente. Num computador é uma regra de firewall persistente ou uma rota predefinida apontada a uma gateway inalcançável.
O custo é que tudo o resto para, por isso as exceções passam a fazer parte do desenho em vez de serem um acrescento. Impressoras locais, descoberta de serviços, inícios de sessão em portais cativos, agentes de gestão e atualizações do sistema operativo precisam cada um de um buraco documentado, porque cada um é um caminho que fica aberto quando o túnel está em baixo. O bloqueio é apenas tão forte como a entrada mais curta dessa lista.
DNS, IPv6 e auxiliares em segundo plano escondem as fugas
O facto de uma aplicação protegida não resolver um nome não prova que as respostas em cache ou o tráfego IP direto estejam bloqueados. Se o resolvedor ainda estiver acessível fora do túnel, o nome resolve-se e a ligação falha, o que parece um interruptor a funcionar e não é. Pior ainda, um registo em cache pode apontar para um endereço que o túnel não transporta, pelo que a ligação sai diretamente enquanto a aplicação relata um erro de VPN.
O IPv6 precisa da sua própria regra em todas as plataformas que o executam, porque uma regra de descarte para v4 não cobre uma rota v6. No telemóvel, uma definição de DNS privado pode mover a resolução para um canal cifrado que a política do dispositivo não inspeciona. E os auxiliares em segundo plano são o culpado habitual no computador: um processo de atualização ou de sincronização na bandeja começa antes do cliente VPN e mantém a sua própria ligação, por isso nunca vê a rota alterada.
Teste três aplicações e duas transições
| 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 linha duas vezes, uma com um nome de anfitrião e outra com um endereço literal, e mais uma vez por IPv6 se a rede o oferecer. Um êxito significa que a aplicação incluída parou, a excluída comportou-se como escreveu e o auxiliar não escapou. Registe o comportamento direto que decidiu ser aceitável, para que o próximo administrador distinga uma exceção deliberada de uma falha.
Depois descreva o resultado numa frase que nomeie as aplicações e as condições, por exemplo: o cliente de salários não tem rota fora do túnel, o navegador é direto por desenho e tudo o resto para quando o túnel está em baixo. Se essa frase for difícil de escrever, a política ainda são duas políticas a lutar entre si.