Como as regras de domínio do Apple VPN On Demand acionam um túnel
Uma regra de domínio só decide quando o túnel abre. Como funciona a sondagem DNS connect-if-needed, por que as rotas ainda escolhem tráfego e como testar o perfil.
O túnel abre quando você solicita um nome interno e permanece fechado quando o próximo aplicativo precisa dele com a mesma urgência. Isso não é um bug do aplicativo; é a forma de uma regra de domínio. A configuração on-demand da Apple descreve condições para estabelecer uma conexão, e a forma de domínio dessas condições pergunta ao resolvedor do sistema antes que um único pacote se mova. Duas perguntas são confundidas o tempo todo: quando o túnel deve subir e o que o túnel transporta depois de existir. A primeira é um gatilho, a segunda é uma política de rotas e resolvedor, e um perfil normalmente define as duas no mesmo payload, por isso uma regra de domínio correta ainda pode deixar você na rede errada.
Gatilho e seleção de tráfego ficam em camadas diferentes
Uma regra on-demand vive no dicionário on-demand de um payload VPN: uma lista ordenada de regras, cada uma com uma ação e um conjunto de condições de correspondência. O sistema as avalia quando a conectividade muda ou quando algo tenta alcançar a rede, e a ação decide se o túnel é levantado, avaliado, desconectado ou ignorado. Tudo isso acontece na camada de rede da plataforma, antes de o seu aplicativo ter um socket.
O que vem a seguir é um grupo separado de chaves: as configurações IPv4 e IPv6 do túnel, as rotas incluídas e excluídas, os endereços dos servidores DNS e, no iOS e iPadOS, o mapeamento por aplicativo que decide quais aplicativos podem usar o túnel. Um perfil pode combinar um gatilho amplo com uma rota estreita, ou um gatilho estreito com uma rota padrão. Leia apenas uma metade e a outra parecerá um mau funcionamento.
Tenho um perfil de laboratório que se conecta sempre que algo sob um domínio interno é solicitado, mas só encaminha uma /16 para o túnel. Ele faz exatamente o que o payload diz, e também é o tipo de perfil que gera chamados: as pessoas presumem que um túnel conectado significa que o tráfego está dentro dele.
O que uma regra de domínio realmente pergunta ao resolvedor
A forma de domínio da regra, frequentemente chamada de connect-if-needed, não inspeciona payloads de pacotes nem observa URLs. Quando um nome é resolvido, o sistema o compara com os domínios da regra e, em caso de correspondência, pergunta se esse nome pode ser resolvido pelos servidores DNS que o túnel fornece. Se o resolvedor do túnel responder, o nome conta como interno e a conexão começa. Se o resolvedor local responder, o nome é tratado como externo e nenhum túnel aparece. A visão geral de implantação da Apple descreve isso como detecção de rede seguida de avaliação de conexão.
Duas consequências decorrem. O perfil precisa nomear servidores DNS dentro do túnel; uma regra de domínio sem resolvedor de túnel não tem o que comparar, então a avaliação não pode produzir a correspondência esperada. E a consulta precisa alcançar o resolvedor do sistema. Um aplicativo ou navegador que executa seu próprio DNS criptografado, uma extensão que responde localmente ou uma conexão com um endereço literal nunca produzem a resolução de nome que a regra esperava. Uma das tardes mais longas que já passei terminou quando descobri que o cliente na frente do túnel usava DNS over HTTPS.
O cache também remove o gatilho. Um nome que já está no cache pode ser respondido sem a sondagem que teria iniciado o túnel, então uma regra que funcionava ontem falha depois de um reinício, ou depois que o túnel ficou no ar por um tempo. No macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder redefine o estado; no iOS, alternar o modo avião ou reiniciar o dispositivo dá uma lousa limpa comparável.
Escopo de correspondência: nomes, aplicativos e redes
A correspondência de domínio é um tipo entre vários. Uma regra também pode corresponder ao tipo de interface (Wi-Fi, celular, Ethernet) e a um SSID específico, e as entradas por aplicativo ou domínio do Safari vinculam um túnel a um fluxo de trabalho. Esse vínculo explica a experiência estranha em que apenas um aplicativo se comporta de forma diferente de todo o resto: os outros aplicativos estão fora do escopo do túnel, então continuam usando o caminho local mesmo quando o ícone do túnel diz conectado.
A ordem importa mais do que as pessoas esperam. As regras são avaliadas em sequência e a primeira que corresponde fornece a ação, então uma regra ampla de conectar-em-qualquer-Wi-Fi colocada acima de uma regra de domínio estreita vence em silêncio e torna a regra de domínio impossível de testar. Antes de reescrever a lista de domínios, confirme que nenhuma regra anterior já correspondeu.
É por isso que always-on não é apenas uma regra on-demand mais rígida. A aplicação de always-on é um modo de implantação separado com seus próprios requisitos de supervisão e gestão; ele mantém um túnel aberto em vez de reagir a um nome. Se o que você precisa é de um túnel que nunca cai, uma regra de domínio é a ferramenta errada.
Modos de falha que imitam uma regra quebrada
A maioria dos relatos de que uma regra de domínio não funciona cai em um de cinco lugares, e só o último deles é o texto da regra.
| What you see | Layer | First check |
|---|---|---|
| Tunnel comes up, internal site still fails | route or resolver after connect | netstat -rn, scutil --dns |
| Tunnel never comes up for that name | trigger path | fresh lookup, cache flush, private DNS |
| Tunnel comes up for every app | scope, or an earlier rule | rule order, per-app mapping |
| Tunnel drops and will not return on the same Wi-Fi | interface or SSID match, admission | captive portal, SSID string, auth prompt |
| Tunnel returns after you disconnect it | profile ownership | profiles show |
Os portais cativos merecem sua própria linha, porque o Wi-Fi de hotéis e aeroportos intercepta exatamente a consulta da qual a regra depende. Até que o portal libere o dispositivo, o servidor DNS do túnel é inalcançável, a sondagem falha e a falha parece um domínio escrito errado. A autenticação é o outro caso silencioso: a regra pode disparar, o túnel pode começar a conectar e a conexão morre em um certificado expirado ou em um prompt que aparece em outra tela.
O IPv6 cria uma variante fácil de diagnosticar mal. Um nome com as duas famílias de endereços pode ser respondido primeiro a partir de um registro AAAA, enquanto a lista de rotas do túnel carrega apenas IPv4. Um navegador funciona, outro falha, e a lista de domínios é completamente inocente.
Teste com uma solicitação real, nesta ordem
Leia a política antes de adivinhar. No macOS, sudo profiles show -type configuration imprime os perfis instalados, incluindo o payload VPN, scutil --nc list mostra o estado do serviço e scutil --nc show <service> imprime o dicionário on-demand que o sistema usa. Em um iPhone ou iPad gerenciado, o mesmo payload vem do console de gestão ou de um relatório MDM. Os logs de rede estão disponíveis com log stream --predicate 'subsystem == "com.apple.networkextension"' no macOS e pelo console do dispositivo quando o telefone está conectado.
Depois teste com um nome de host que não foi consultado antes na sessão. Escolha um nome na zona DNS do túnel que você sabe que resolve internamente, solicite-o uma vez e observe se o túnel aparece. Execute a mesma consulta duas vezes: a segunda tentativa exercita o caminho do cache, e a diferença entre as duas diz se o gatilho é a resolução ou o roteamento.
Depois que o túnel estiver no ar, verifique as duas camadas separadamente. netstat -rn -f inet e netstat -rn -f inet6 mostram para onde cada prefixo aponta, scutil --dns mostra a ordem dos resolvedores e qual interface possui cada resolvedor, e nettop -m route mostra qual interface transportou os bytes. Se o túnel está no ar e o resolvedor está correto, mas o recurso ainda falha, pare de editar a regra; verifique a autorização do servidor e a rota de retorno.
Quando a regra pertence a outra pessoa
Se o túnel reaparece depois que você o desconecta, a regra geralmente pertence a um perfil e não a um aplicativo: uma configuração enviada por MDM, um perfil pessoal remanescente ou um perfil instalado por outro cliente. sudo profiles show -type configuration mais uma busca pelas chaves on-demand vai restringir isso, e o caminho de remoção é o perfil, não o interruptor na barra de menus. Excluir a entrada de serviço ou o aplicativo deixa a regra para trás, e a próxima instalação a herda novamente.
Um único teste resolve a propriedade: desconecte, espere, solicite o nome interno novamente. Se o túnel voltar, o gatilho está funcionando como projetado e a pergunta em aberto é quem o gerencia e se esse escopo é o que você quer.
Antes de registrar isso como bug, percorra as mesmas cinco verificações: endereços do resolvedor do túnel presentes no payload, um nome que não estava em cache, nenhuma regra anterior que já correspondesse, uma rota AAAA coberta pela lista de rotas e o aplicativo dentro do escopo do túnel. Quando as cinco se mantêm, a regra faz seu trabalho e a falha está mais adiante no caminho.