Qual ferramenta do macOS consegue forçar uma única app a passar apenas pela VPN?

Uma linha num documento de requisitos, «esta app pode usar a VPN e nada mais», pede em silêncio dois mecanismos que nenhum interruptor fornece. O tráfego precisa de um caminho pelo túnel previsto, e o tráfego que sairia diretamente tem de ser recusado. Ferramentas que fazem bem uma dessas coisas e a outra não fazem nada são comuns, por isso uma comparação que só pergunta se algo consegue bloquear responde com confiança a metade da pergunta. Escreva primeiro o limite e depois escolha os componentes que cobrem as suas duas metades.

Dois requisitos escondidos numa só frase

O encaminhamento é a parte que coloca uma ligação no túnel ou no proxy. A recusa é a parte que impede a mesma ligação de sair por qualquer outra rota. Implementam-nas componentes diferentes, falham de formas diferentes, e um produto pode ser excelente numa e nada dizer sobre a outra:

Leia a tabela como uma lista de verificação e não como uma classificação. Nenhuma linha preenche as duas colunas centrais, e as linhas que as cobrem são dois componentes que cooperam: um possui o caminho e o outro possui a recusa. A coluna de identidade importa por outro motivo, porque uma regra que não consegue nomear a app não consegue aplicar uma regra sobre essa app. Faça o que fizer, tem de responder às três, ou o limite do documento de requisitos não é o limite na máquina.

O encaminhamento sozinho deixa uma saída

A definição de proxy de aplicação é o exemplo mais claro de encaminhamento sem recusa. Pode encaminhar pedidos de uma app que respeita o proxy do sistema e não cobre nada mais: um processo auxiliar, um atualizador, um serviço em segundo plano ou um protocolo diferente podem seguir o seu próprio caminho sem nunca ler essa definição. Escolher um ponto final SOCKS num painel não cria, por isso, uma política de saída direta proibida para a aplicação. Se o requisito for sobre a app no seu todo, pergunte que componentes a regra identifica realmente.

Um perfil de VPN por app encaminha melhor do que um proxy, porque é a plataforma que decide que apps entram no túnel em vez de cada app decidir por si. Ainda assim não recusa nada: o perfil fornece um caminho, e o tráfego que não se encaixa nele segue a rota normal. É exatamente nessa falha que um segundo componente ganha o seu lugar, e é por isso que os produtos que parecem um só interruptor costumam ser dois.

A recusa sozinha quebra a app

A documentação da Apple sobre filtros de conteúdo descreve um veredicto de permitir-ou-bloquear sobre o tráfego enquanto passa pela pilha de rede. Esse veredicto não é um túnel nem uma ligação proxy, porque decide se algo pode continuar, não para onde vai. Um filtro sozinho aplica a recusa na perfeição e deixa a aplicação inutilizável, com registos limpos e sem explicação. O veredicto de um filtro pode parar uma ligação mas nunca fornece o túnel, por isso emparelhá-lo com o encaminhamento é a decisão de desenho e não um extra opcional.

Um conjunto de regras PF administrado localmente fica no outro extremo desse espetro. É uma decisão de suporte legítima numa máquina que um administrador possui, e não é automaticamente a base de um produto distribuível, porque quem possui o conjunto de regras também possui as suas interações com outros utilizadores da firewall, o caminho de atualização e a recuperação quando uma regra está errada. Acrescentar PF a um produto não elimina essa questão de propriedade; define-a.

A implementação decide se a regra ainda existe amanhã

A forma como uma Network Extension é implementada nas plataformas Apple depende do tipo de fornecedor, do empacotamento e da versão do sistema operativo à sua frente. Uma extensão de app no macOS corre num contexto de utilizador e termina quando esse utilizador termina sessão, enquanto uma extensão de sistema tem um contexto global que não depende da sessão. Se a proteção tem de sobreviver a um fim de sessão, essa diferença é todo o desenho e não uma nota de rodapé. Confirme o caminho de implementação antes de prometer o comportamento, porque o mesmo código aterra de forma diferente conforme o tipo de extensão enviado.

A disponibilidade do código-fonte é uma questão separada da aplicação. Ler um repositório diz-lhe como algo está implementado, não o que o binário instalado pode fazer nesta máquina. A assinatura, a instalação e a autorização continuam a aplicar-se, e instruções construídas em torno de uma extensão de kernel obsoleta ou de um truque de injeção de biblioteca descrevem outra plataforma e outra postura de risco, por bem que funcionassem em tempos.

Um caso de aceitação que nomeia a app

Escolha uma única ação que a aplicação realize sozinha, anote o endereço que deveria alcançar e se esse endereço é IPv4 ou IPv6, e repita depois a mesma ação no estado aprovado sem túnel. A segunda execução tem de produzir a recusa declarada e não uma nova tentativa direta silenciosa. É essa metade que as pessoas deixam por especificar, e a única metade que prova que a recusa existe. Execute-a primeiro com o túnel disponível, para que uma diferença entre os dois resultados só possa vir do túnel em falta.

Depois percorra as transições que o requisito nomeia: reiniciar a app, o disparo de um processo auxiliar, a reconexão do túnel, a mudança de redes da máquina e um fim de sessão ou reinício onde se apliquem. Uma página de IP público no navegador não é um teste dos sockets de outra aplicação, por isso não pode substituir esta. Onde nenhuma implementação suportada cobre o comportamento real da app, um ambiente isolado autorizado com um gateway explícito e sem saída alternativa é uma decisão de contenção com o seu próprio custo de gestão, não um substituto de uma caixa de verificação.

Termine escrevendo quatro entradas: que componentes formam a app, quem possui o encaminhamento, quem possui a recusa e os estados em que a regra ainda tem de valer. Um repositório público pode ser um critério de seleção, mas não é uma das quatro, e são essas entradas que decidem se uma dada ferramenta cumpre o requisito de rede.