Onde tem de ficar uma regra de firewall do Android com a VPN ligada

Tem uma frase de política: esta aplicação pode chegar ao serviço de trabalho e a mais nada. A pergunta seguinte parece uma escolha de produto, mas é uma pergunta de localização, porque cada ponto de aplicação possível vê um subconjunto diferente do tráfego do telemóvel. Um gateway vê apenas o que entra no túnel. Um filtro do lado do telemóvel vê apenas o que lhe é permitido observar. Passar um único pedido pelos dois torna a resposta óbvia.

Comece pela frase, não pelo produto

Expanda o requisito antes de escolher seja o que for. Isso significa o pacote e o perfil em que corre, porque uma aplicação de perfil de trabalho é um utilizador diferente da mesma aplicação no perfil pessoal. Significa o destino: anfitrião, porta e protocolo, não o nome de um serviço. Significa o caminho DNS que resolve esse nome e significa o que deve acontecer quando o túnel não está disponível.

Escrita, a política do exemplo tem quatro linhas: a aplicação de trabalho pode chegar ao serviço de trabalho; a aplicação de trabalho não pode chegar a mais nada; as outras aplicações ficam inalteradas; sem túnel, a aplicação de trabalho é negada em vez de recorrer a outra via. Cada linha tem um responsável, e não são todos o mesmo responsável.

Passo 1: o que o próprio telemóvel pode aplicar

Uma firewall Android sem root é um VpnService que captura o tráfego localmente, mesmo quando não há nenhum túnel remoto por trás. O Android permite um único serviço VPN ativo por perfil de utilizador, por isso uma segunda aplicação de firewall não se encadeia atrás da primeira. Substitui-a, e a interface que a primeira aplicação estava a filtrar desaparece.

É por isso que instalar uma firewall ao lado de um cliente VPN raramente produz a combinação que as pessoas esperam. Se a firewall arranca e a VPN se desliga, nada foi combinado; as duas trocaram de lugar. Uma substituição de interface não é cooperação, e o sintoma é um túnel que cai sempre que a outra aplicação é aberta.

Existem arranjos suportados: filtragem integrada no cliente VPN que já utiliza, controlos geridos da plataforma através de um controlador de políticas do dispositivo ou de um perfil de trabalho, ou uma arquitetura documentada pelo fornecedor. Tudo o resto é uma experiência que tem de ser verificada de novo após cada atualização das aplicações.

Passo 2: o que o gateway pode aplicar

Assim que o tráfego é desencriptado no extremo distante, o gateway pode restringir os pacotes reencaminhados a endereços, serviços ou identidades VPN autenticadas aprovados. Isso é aplicação genuína para tudo o que sai por ele, e é o local certo para limitar o acesso a sub-redes privadas.

O que não recebe é a identidade da aplicação do telemóvel associada a cada pacote IP comum. Várias aplicações a partilhar um endereço de túnel são um único sujeito para o gateway, a menos que o desenho lhes dê endereços separados ou identidades autenticadas separadas. Uma regra por utilizador no gateway não é, portanto, uma regra por aplicação no telemóvel, independentemente do nome que a consola de gestão lhe dê.

Passo 3: liste o que nunca chega

Uma aplicação excluída da VPN que contacta um dispositivo próximo nunca chega ao gateway, por isso uma firewall de saída não pode recusar um pacote que nunca recebe. O mesmo se aplica a uma rota direta não intencional durante uma falha e à exposição de entrada na rede de acesso local. Esses são limites locais por definição.

O inverso também é verdadeiro: uma regra local que permite uma ligação não concede acesso através da ACL de rede privada do gateway. Um pedido pode estar sujeito aos dois limites, e satisfazer um não diz nada sobre o outro.

Passo 4: atribua cada regra a um caminho

Coloque a decisão numa tabela antes de configurar seja o que for, porque as células em branco são onde os desenhos falham.

A forma viável são dois limites com duas funções. Um limite local consciente das aplicações governa o comportamento do telemóvel, incluindo o recurso direto, e um limite de gateway governa os recursos remotos. O lado do gateway pode permitir o serviço de trabalho e recusar todas as outras sub-redes privadas, enquanto a política do lado do telemóvel decide por si sobre um caminho direto que a aplicação poderia de outro modo tomar.

Passo 5: mantenha o transporte vivo e depois verifique

Seja qual for a política local a que chegar, tem de permitir o transporte que estabelece e mantém a VPN. Bloquear esse transporte deixa o telemóvel sem túnel e sem política, o que não aplica nada de forma coerente e é difícil de diagnosticar porque a aplicação simplesmente não tem rede.

Depois verifique cada linha da frase original em vez da impressão geral: a aplicação de trabalho chega ao serviço de trabalho, a mesma aplicação é recusada noutro destino, uma aplicação que não é de trabalho comporta-se como antes e, com o túnel parado, a aplicação de trabalho não recorre a uma ligação direta. Verifique o caminho DNS em separado, porque um DNS privado ou um resolvedor encriptado podem contornar um filtro que só inspeciona endereços.

Se um desses passos não puder ser satisfeito no telemóvel, o requisito é uma questão de arquitetura e não uma definição de firewall. Dividir a política entre um dispositivo que controla e um gateway que controla é normalmente a resposta honesta, e a documentação de conectividade VPN do Android é o local para confirmar o que a plataforma deixará e não deixará um único serviço fazer.