Bloqueio VPN PF no Mac: uma política do site, não um recurso distribuível

Isto funciona no seu Mac, por isso parece algo que pode entregar aos utilizadores. Essa suposição é a primeira coisa a abandonar. O documento TN3165 da Apple afirma claramente que o Packet Filter não é uma API suportada para produtos distribuídos em geral, e enquadra a administração de site privilegiada e controlada como o caso razoável. Um bloqueio VPN construído sobre PF é, portanto, uma política operacional local com um responsável, não um recurso que possa ser entregue dentro de uma aplicação.

O PF não é uma superfície de empacotamento

A distinção não é académica. Um produto distribuído que dependa do PF herda cada alteração que a Apple lhe faz, cada conflito com outra ferramenta que também escreva regras, e nenhum compromisso de suporte de que o arranjo continuará a funcionar. Um site que administra as suas próprias máquinas tem uma relação diferente: pode documentar a dependência, testá-la contra cada versão do sistema operativo e aceitar a manutenção.

Alguns conselhos de instalação ultrapassam uma linha que vale a pena nomear. Substituir todo o conjunto de regras do sistema para carregar uma âncora, editar a configuração de arranque do sistema da Apple ou desativar o System Integrity Protection não são requisitos aceitáveis para uma receita reutilizável. Se um guia publicado precisa de alguma dessas coisas, está a descrever um laboratório, não uma política implementável.

Escreva a intenção de saída antes da sintaxe

Decida o que é permitido antes de escolher uma única palavra-chave. Habitualmente têm de existir três caminhos: o transporte do próprio cliente VPN até ao seu servidor, o tráfego protegido da aplicação dentro do túnel e tudo o que a configuração ou os serviços locais realmente exigem um caminho direto.

Dê a cada exceção proposta um destino, um transporte e um responsável. Permitir todas as portas para um endpoint permite muito mais do que o único transporte que o túnel utiliza, e a exposição extra surge sem que ninguém tenha decidido que assim deve ser. Permitir um resolver público é a mesma armadilha com uma roupa mais amigável: cria um caminho DNS direto mesmo com o túnel em baixo, pelo que as consultas de nomes continuam a escapar.

O teste útil para uma exceção é saber se consegue nomear a pessoa que a pediu e a falha que ela evita. Se nenhuma das respostas existir, a regra é provavelmente um contorno para uma configuração errada que, de outra forma, permaneceria invisível.

Os números utun não são uma identidade

O MacOS cria interfaces de túnel como dispositivos utun, e o número atribuído à sua VPN não é estável entre reinícios, reconexões ou a presença de outro cliente. Uma regra que lista vários números adivinhados não é uma política; é uma fotografia de uma tarde.

Ancore a regra em algo que identifique o fornecedor pretendido: o plano de endereços que o túnel atribui, o processo que é dono da interface ou uma configuração que o próprio cliente VPN mantém. Depois registe como funciona essa identificação, porque a pessoa que rever a regra dentro de um ano não terá o seu histórico de shell.

Torne a política carregada atribuível

Um nome de âncora organiza regras; não prova que a política efetiva é a que pretendia. A precedência entre âncoras, as regras carregadas por outro software e o estado existente podem todos alterar o resultado. Reveja o conjunto efetivo com todos os outros responsáveis pelo PF nessa máquina e documente a propriedade no mesmo local da configuração. Dois responsáveis a editar âncoras diferentes com pressupostos diferentes é a forma comum de um bloqueio ganhar um buraco.

Mantenha o conjunto de regras no caminho de configuração suportado pelo site, versione-o e anote que versões do macOS foram testadas. Uma alteração aplicada à mão e memorizada por uma pessoa não é infraestrutura mantida, diga o que disser o cabeçalho do ficheiro.

Teste as transições, não o estado ligado

Uma captura de ecrã tirada com o túnel ativo não prova quase nada. Percorra os estados: arranque antes de qualquer ligação, um túnel a funcionar, um túnel que cai sem aviso, uma desconexão deliberada e uma mudança de Wi-Fi para um hotspot. Cada estado tem a sua própria resposta, e os interessantes são as falhas, não o caminho feliz.

Em cada estado, registe o que é intencionalmente alcançável. Verifique IPv4 e IPv6 separadamente, teste a resolução de nomes e inclua um fluxo que já estava estabelecido antes da transição, porque as ligações existentes nem sempre seguem a nova política. Um navegador que falha com o túnel em baixo é um ponto de dados, não prova de que todos os outros caminhos estão bloqueados.

Por fim, mantenha um método de recuperação que não dependa do caminho de rede que está a alterar. Uma configuração boa conhecida em armazenamento local e uma forma documentada de a carregar transformam um bloqueio numa política; sem elas, uma revisão má tranca o administrador fora da máquina que devia estar protegida.