Como as regras de dominio de Apple VPN On Demand abren un túnel

O túnel ábrese cando solicitas un nome interno e permanece pechado cando a seguinte aplicación o necesita con igual urxencia. Iso non é un erro da aplicación; é a forma dunha regra de dominio. A configuración on-demand de Apple describe condicións para establecer unha conexión, e a forma de dominio desas condicións fai unha pregunta ao resolutor do sistema antes de que se mova un só paquete. Dúas preguntas confúndense constantemente: cando debe subir o túnel e que transporta o túnel unha vez existe. A primeira é un desencadenante, a segunda é unha política de rutas e resolutor, e un perfil adoita configurar ambas no mesmo payload, por iso unha regra de dominio correcta pode deixarte igualmente na rede equivocada.

O desencadenante e a selección de tráfico están en capas distintas

Unha regra on-demand vive no dicionario on-demand dun payload VPN: unha lista ordenada de regras, cada unha cunha acción e un conxunto de condicións de coincidencia. O sistema avalíaas cando cambia a conectividade ou cando algo tenta chegar á rede, e a acción decide se o túnel se levanta, se avalía, se desconecta ou se ignora. Todo isto ocorre na capa de rede da plataforma, antes de que a túa aplicación teña un socket.

O que ocorre despois é un grupo separado de claves: os axustes IPv4 e IPv6 do túnel, as súas rutas incluídas e excluídas, os enderezos dos seus servidores DNS e, en iOS e iPadOS, o mapeo por aplicación que decide que aplicacións poden usar o túnel. Un perfil pode combinar un desencadenante amplo cunha ruta estreita, ou un desencadenante estreito cunha ruta predeterminada. Le só unha metade e a outra parecerá un mal funcionamento.

Teño un perfil de laboratorio que se conecta sempre que se solicita algo baixo un dominio interno, pero só encamiña unha /16 cara ao túnel. Fai exactamente o que di o seu payload, e tamén é o tipo de perfil que xera tíckets: a xente asume que un túnel conectado significa que o seu tráfico está dentro.

Que lle pregunta realmente unha regra de dominio ao resolutor

A forma de dominio da regra, a miúdo chamada connect-if-needed, non inspecciona os payloads dos paquetes nin observa URL. Cando se resolve un nome, o sistema compárao cos dominios da regra e, se coincide, pregunta se ese nome se pode resolver a través dos servidores DNS que proporciona o túnel. Se responde o resolutor do túnel, o nome conta como interno e iníciase a conexión. Se en cambio responde o resolutor local, o nome trátase como externo e non aparece ningún túnel. A descrición xeral de despregamento de Apple descríbeo como detección de rede seguida de avaliación de conexión.

Derívanse dúas consecuencias. O perfil debe nomear servidores DNS dentro do túnel; unha regra de dominio sen resolutor de túnel non ten nada que comparar, así que a avaliación non pode producir a coincidencia que esperas. E a consulta debe chegar ao resolutor do sistema. Unha aplicación ou un navegador que executa o seu propio DNS cifrado, unha extensión que responde localmente ou unha conexión a un enderezo literal nunca producen a resolución de nome que a regra agardaba. Unha das tardes máis longas que pasei rematou cando descubrín que o cliente diante do túnel usaba DNS over HTTPS.

A caché tamén elimina o desencadenante. Un nome que xa está na caché pode responderse sen a sonda que tería iniciado o túnel, así que unha regra que funcionaba onte falla tras un reinicio ou despois de que o túnel estivese arriba un tempo. En macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder restablece o estado; en iOS, activar e desactivar o modo avión ou reiniciar o dispositivo dache unha lousa limpa comparable.

Alcance de coincidencia: nomes, aplicacións e redes

A coincidencia de dominio é un tipo entre varios. Unha regra tamén pode coincidir co tipo de interface (Wi-Fi, móbil, Ethernet) e unha SSID concreta, e as entradas por aplicación ou dominio de Safari vinculan un túnel a un fluxo de traballo. Ese vínculo explica a estraña experiencia na que só unha aplicación se comporta distinto de todo o demais: as outras están fóra do alcance do túnel, así que seguen usando a ruta local mesmo cando a icona do túnel di conectado.

A orde importa máis do que a xente espera. As regras avalíanse en secuencia e a primeira que coincide achega a acción, así que unha regra ampla de conectar-en-calquera-Wi-Fi colocada por riba dunha regra de dominio estreita gañará en silencio e fará que a regra de dominio non se poida probar. Antes de reescribir a lista de dominios, confirma que ningunha regra anterior xa coincidiu.

Por iso always-on tampouco é só unha regra on-demand máis estrita. A aplicación de always-on é un modo de despregamento aparte cos seus propios requisitos de supervisión e xestión; mantén un túnel aberto en lugar de reaccionar a un nome. Se o que necesitas é un túnel que nunca caia, unha regra de dominio é a ferramenta equivocada.

Modos de fallo que imitan unha regra rota

A maioría dos informes de que unha regra de dominio non funciona acaban nun de cinco lugares, e só o último é o texto da regra.

Os portais cativos merecen a súa propia liña, porque o Wi-Fi de hoteis e aeroportos intercepta xusto a consulta da que depende a regra. Ata que o portal admite o dispositivo, o servidor DNS do túnel é inalcanzable, a sonda falla e o fallo parece un dominio mal escrito. A autenticación é o outro caso silencioso: a regra pode dispararse, o túnel pode comezar a conectar e a conexión morre nun certificado caducado ou nun aviso que aparece noutra pantalla.

IPv6 crea unha variante fácil de diagnosticar mal. Un nome con ambas as familias de enderezos pode responderse primeiro desde un rexistro AAAA, mentres que a lista de rutas do túnel só leva IPv4. Un navegador logra, outro falla, e a lista de dominios é completamente inocente.

Proba cunha solicitude real, nesta orde

Le a política antes de facer conxecturas. En macOS, sudo profiles show -type configuration imprime os perfis instalados, incluído o payload VPN, scutil --nc list mostra o estado do servizo e scutil --nc show <service> imprime o dicionario on-demand que usa o sistema. Nun iPhone ou iPad supervisado, o mesmo payload chega da consola de xestión ou dun informe MDM. Os rexistros de rede están dispoñibles con log stream --predicate 'subsystem == "com.apple.networkextension"' en macOS e a través da consola do dispositivo cando o teléfono está conectado.

Despois proba cun nome de host que non se consultase antes na sesión. Escolle un nome na zona DNS do túnel que saibas que se resolve internamente, solicítao unha vez e observa se aparece o túnel. Executa a mesma consulta dúas veces: o segundo intento exercita a ruta da caché, e a diferenza entre ambos diche se o desencadenante é a resolución ou o encamiñamento.

Unha vez arriba o túnel, verifica as dúas capas por separado. netstat -rn -f inet e netstat -rn -f inet6 mostran cara a onde apunta cada prefixo, scutil --dns mostra a orde dos resolutores e que interface posúe cada un, e nettop -m route mostra que interface transportou os bytes. Se o túnel está arriba e o resolutor é correcto pero o recurso segue fallando, deixa de editar a regra; comproba a autorización do servidor e a ruta de volta.

Cando a regra é doutra persoa

Se o túnel reaparece despois de desconectalo, a regra adoita pertencer a un perfil e non a unha aplicación: unha configuración enviada por MDM, un perfil persoal sobrante ou un perfil instalado por outro cliente. sudo profiles show -type configuration máis unha busca das claves on-demand acoutarao, e a ruta de eliminación é o perfil, non o interruptor da barra de menús. Borrar a entrada do servizo ou a aplicación deixa a regra atrás, e a seguinte instalación hérdana de novo.

Unha soa proba resolve a propiedade: desconecta, espera, solicita o nome interno outra vez. Se o túnel volve, o desencadenante funciona como se deseñou e a pregunta aberta é quen o xestiona e se ese alcance é o que queres.

Antes de rexistrar isto como un erro, percorre as mesmas cinco comprobacións: enderezos do resolutor do túnel presentes no payload, un nome que non estaba na caché, ningunha regra anterior que xa coincidise, unha ruta AAAA que cubra a lista de rutas e a aplicación dentro do alcance do túnel. Cando as cinco se cumpren, a regra fai o seu traballo e o fallo está máis adiante na ruta.