VPN do Mac, filtro de conteúdo ou Private Relay: qual está ativo
Três camadas de rede do Mac parecem iguais nos Ajustes. Distinga uma VPN, um filtro de conteúdo e o Private Relay pelo caminho de saída, pela política de fluxos e pelo âmbito de navegação.
O seu Mac pode ter instalados ao mesmo tempo um túnel VPN, um filtro de conteúdo e o iCloud Private Relay, e nenhum deles anuncia qual está a moldar uma dada ligação. Os painéis de ajustes parecem iguais, os ícones parecem iguais, e quase todos os fornecedores chamam segurança de rede ao seu produto. Três factos separam-nos: se o tráfego sai por um ponto remoto que consiga nomear, se um motor de políticas decide permitir-ou-descartar em fluxos individuais, e se a proteção termina no Safari. Com estes três esclarecidos, a maioria das perguntas de o-meu-VPN-está-ligado responde-se sozinha.
Três condições que identificam o componente
A primeira condição é a saída. Um fornecedor de túnel entrega os pacotes a um gateway remoto, pelo que o seu endereço público muda e, se o perfil o indicar, os anfitriões atrás desse gateway tornam-se alcançáveis. Se o endereço nunca muda e nenhuma sub-rede privada se abre, não está a ver um túnel funcional, diga o que disser a barra de menus.
A segunda condição é a decisão. Um filtro de conteúdo avalia fluxos e devolve permitir ou descartar. Pode impor um bloqueio de categoria, uma regra por aplicação ou uma política enviada pelo empregador, e pode registar o veredicto. O que não consegue fazer sozinho é dar ao tráfego um lugar para onde ir.
A terceira condição é o âmbito. O Private Relay protege uma fatia definida da navegação e não um dispositivo inteiro, e a sua função é separar quem você é do que visita, não colocá-lo noutra rede.
Coloque os três lado a lado e os limites são difíceis de perder:
| Layer | Question it answers | Evidence to look for | What it does not do |
|---|---|---|---|
| VPN tunnel provider | Where does my traffic emerge, and which private networks can I reach? | Changed public address, a connected service, a default route through a utun interface | Enforce per-app content policy |
| Content filter | May this flow proceed, and who decided? | A filter extension in Network Extensions, drop verdicts, an MDM profile | Supply a different public exit |
| iCloud Private Relay | Can the local network see which sites Safari loads? | A relay egress address in Safari only, the relay toggle in iCloud settings | Cover other apps or grant access to a private subnet |
Um filtro de conteúdo é um motor de políticas, não uma saída
No macOS um filtro chega como uma Network Extension construída sobre a classe de fornecedor de dados de filtragem da Apple, NEFilterDataProvider. Numa implantação gerida, o MDM empurra-o, é instalado como extensão de sistema e aprovado uma vez em Ajustes do Sistema > Geral > Itens de início e extensões. A partir daí vê fluxos TCP, e nalgumas configurações também UDP, e devolve um veredicto para cada um.
O modo de falha é o que confunde as pessoas. Um filtro que descarta um fluxo produz um tempo de espera esgotado, um aperto de mão TLS bloqueado ou um reinício, o que se parece exatamente com um túnel que subiu mas não consegue passar tráfego. O endereço público nunca mudou, porque nunca houve uma saída que o mudasse.
Os clientes comerciais costumam juntar os dois papéis. Um único instalador traz um fornecedor de túnel e um filtro, o filtro faz o bloqueio e o túnel faz o encaminhamento. O nome da aplicação não lhe diz, portanto, nada sobre qual componente recusou a ligação. Verifique a lista de extensões, depois o serviço ligado, depois o registo do cliente, nessa ordem.
O Private Relay cobre o Safari, não a máquina
O Private Relay envia a navegação que cobre através de dois relés operados por partes separadas, pelo que nenhum operador único detém ao mesmo tempo a sua identidade e os seus destinos. Isto é um desenho de privacidade, não um túnel: não há gateway onde entrar, nem sub-rede privada, nem forma de fixar um endereço de saída num país que escolha.
O seu âmbito é deliberadamente estreito: cobre a navegação no Safari juntamente com as consultas DNS e os carregamentos HTTP inseguros que a acompanham. Uma sessão de terminal, um cliente de correio, uma aplicação de conversação e um lançador de jogos ficam de fora. Se uma verificação no Terminal ainda mostrar o endereço da sua rede de acesso enquanto o Safari mostra um endereço de relé, esse é o resultado esperado, não uma instalação avariada.
A disponibilidade é condicional. Requer um plano iCloud+, não é oferecido em todas as regiões, e uma rede gerida pode bloquear o acesso ao relé, caso em que o Safari volta a uma ligação direta. A visão geral do Private Relay da Apple é a referência para o âmbito atual. Quando um perfil VPN está ligado e transporta esse tráfego, o relé não é empilhado por cima; é o perfil que decide o caminho.
Leia as provas na ordem correta
Comece pelo estado do serviço, porque é o sinal mais barato. scutil --nc list lista os serviços VPN configurados e se cada um está ligado. Um perfil pode ficar ali anos sem nunca ser ligado, e as pessoas costumam contá-lo como um túnel.
Depois olhe para interfaces e rotas. ifconfig mostra interfaces utun, mas a sua presença por si só prova pouco, já que o macOS usa utun para vários fins além da VPN. O que importa é se a rota predefinida aponta para uma delas, o que é reportado por route -n get default.
Para a resolução de nomes, scutil --dns lista os resolvedores que o sistema vai realmente usar, e aí aparece um fornecedor de proxy DNS. Comparar dig +short example.com com dig +short example.com @1.1.1.1 separa o resolvedor que responde do resolvedor que está a ser intercetado.
A atividade das extensões chega ao registo unificado: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Está à procura de que extensão arrancou e se um filtro reportou um veredicto sobre o fluxo que lhe importa, não de uma linha para memorizar.
Estreite o sintoma antes de desativar seja o que for
Classifique primeiro a falha. Um nome que não resolve, uma ligação recusada de imediato e uma ligação que fica pendurada até ao tempo de espera são três observações diferentes com três responsáveis diferentes. A resolução aponta para um resolvedor ou proxy DNS. Uma recusa imediata aponta para uma regra do filtro. O silêncio aponta normalmente para o encaminhamento, ou para um túnel que está levantado mas não reenvia.
Num Mac gerido, assuma que o filtro pertence à organização. Desativá-lo para testar a VPN remove o componente que queria observar, e o MDM restaura-o muitas vezes na verificação seguinte. Peça o nome da política ao administrador antes de mudar seja o que for, e teste com a aplicação concreta que falhou em vez de com todo o sistema.
Mais uma armadilha: desligar o Private Relay para testar uma VPN não diz nada sobre tráfego estrangeiro, porque o relé nunca cobriu esse tráfego. Cada camada tem de ser testada na aplicação que realmente governa.
Percorra esta lista e pare no primeiro ponto que falhar:
scutil --nc listmostra o serviço que espera como ligado?- O endereço público visto no Terminal difere do endereço atribuído pela sua rede de acesso?
- Há uma extensão de filtro instalada, e registou um veredicto para o fluxo que falha?
- A falha é apenas no Safari? Se sim, verifique o âmbito do relé antes de culpar o túnel.
Se os quatro passarem e a aplicação continuar a falhar, o problema está acima da camada de rede: ajustes de proxy, confiança em certificados ou uma lista de permitidos ao nível da aplicação.