Cómo las reglas de dominio de Apple VPN On Demand abren un túnel
Una regla de dominio solo decide cuándo se abre el túnel. Cómo funciona la sonda DNS connect-if-needed, por qué las rutas siguen eligiendo tráfico y cómo probar el perfil.
El túnel se abre cuando solicitas un nombre interno y permanece cerrado cuando la siguiente aplicación lo necesita con la misma urgencia. Eso no es un fallo de la aplicación; es la forma de una regla de dominio. La configuración on-demand de Apple describe condiciones para establecer una conexión, y la forma de dominio de esas condiciones hace una pregunta al resolutor del sistema antes de que se mueva un solo paquete. Dos preguntas se confunden constantemente: cuándo debe subir el túnel y qué transporta el túnel una vez existe. La primera es un desencadenante, la segunda es una política de rutas y resolutor, y un perfil suele configurar ambas en el mismo payload, por eso una regla de dominio correcta puede dejarte igualmente en la red equivocada.
El desencadenante y la selección de tráfico están en capas distintas
Una regla on-demand vive en el diccionario on-demand de un payload VPN: una lista ordenada de reglas, cada una con una acción y un conjunto de condiciones de coincidencia. El sistema las evalúa cuando cambia la conectividad o cuando algo intenta llegar a la red, y la acción decide si el túnel se levanta, se evalúa, se desconecta o se ignora. Todo esto ocurre en la capa de red de la plataforma, antes de que tu aplicación tenga un socket.
Lo que ocurre después es un grupo separado de claves: los ajustes IPv4 e IPv6 del túnel, sus rutas incluidas y excluidas, las direcciones de sus servidores DNS y, en iOS y iPadOS, el mapeo por aplicación que decide qué aplicaciones pueden usar el túnel. Un perfil puede combinar un desencadenante amplio con una ruta estrecha, o un desencadenante estrecho con una ruta predeterminada. Lee solo una mitad y la otra parecerá un mal funcionamiento.
Tengo un perfil de laboratorio que se conecta siempre que se solicita algo bajo un dominio interno, pero solo enruta una /16 hacia el túnel. Hace exactamente lo que dice su payload, y también es el tipo de perfil que genera tickets: la gente asume que un túnel conectado significa que su tráfico está dentro.
Qué pregunta realmente una regla de dominio al resolutor
La forma de dominio de la regla, a menudo llamada connect-if-needed, no inspecciona los payloads de los paquetes ni observa URL. Cuando se resuelve un nombre, el sistema lo compara con los dominios de la regla y, si coincide, pregunta si ese nombre puede resolverse a través de los servidores DNS que proporciona el túnel. Si responde el resolutor del túnel, el nombre cuenta como interno y se inicia la conexión. Si en cambio responde el resolutor local, el nombre se trata como externo y no aparece ningún túnel. La descripción general de despliegue de Apple lo describe como detección de red seguida de evaluación de conexión.
Se derivan dos consecuencias. El perfil debe nombrar servidores DNS dentro del túnel; una regla de dominio sin resolutor de túnel no tiene nada que comparar, así que la evaluación no puede producir la coincidencia que esperas. Y la consulta debe llegar al resolutor del sistema. Una aplicación o un navegador que ejecuta su propio DNS cifrado, una extensión que responde localmente o una conexión a una dirección literal nunca producen la resolución de nombre que la regla esperaba. Una de las tardes más largas que he pasado terminó cuando descubrí que el cliente frente al túnel usaba DNS over HTTPS.
El almacenamiento en caché también elimina el desencadenante. Un nombre que ya está en la caché puede responderse sin la sonda que habría iniciado el túnel, así que una regla que funcionaba ayer falla tras un reinicio o después de que el túnel haya estado arriba un tiempo. En macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder restablece el estado; en iOS, activar y desactivar el modo avión o reiniciar el dispositivo te da una pizarra limpia comparable.
Alcance de coincidencia: nombres, aplicaciones y redes
La coincidencia de dominio es un tipo entre varios. Una regla también puede coincidir con el tipo de interfaz (Wi-Fi, móvil, Ethernet) y una SSID concreta, y las entradas por aplicación o dominio de Safari vinculan un túnel a un flujo de trabajo. Ese vínculo explica la extraña experiencia en la que solo una aplicación se comporta distinto de todo lo demás: las demás están fuera del alcance del túnel, así que siguen usando la ruta local incluso cuando el icono del túnel dice conectado.
El orden importa más de lo que la gente espera. Las reglas se evalúan en secuencia y la primera que coincide aporta la acción, así que una regla amplia de conectar-en-cualquier-Wi-Fi colocada por encima de una regla de dominio estrecha ganará en silencio y hará que la regla de dominio no se pueda probar. Antes de reescribir la lista de dominios, confirma que ninguna regla anterior ya coincidió.
Por eso always-on tampoco es solo una regla on-demand más estricta. La aplicación de always-on es un modo de despliegue aparte con sus propios requisitos de supervisión y gestión; mantiene un túnel abierto en lugar de reaccionar a un nombre. Si lo que necesitas es un túnel que nunca caiga, una regla de dominio es la herramienta equivocada.
Modos de fallo que imitan una regla rota
La mayoría de los informes de que una regla de dominio no funciona acaban en uno de cinco lugares, y solo el último es el texto de la regla.
| 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 |
Los portales cautivos merecen su propia línea, porque el Wi-Fi de hoteles y aeropuertos intercepta justo la consulta de la que depende la regla. Hasta que el portal admite el dispositivo, el servidor DNS del túnel es inalcanzable, la sonda falla y el fallo parece un dominio mal escrito. La autenticación es el otro caso silencioso: la regla puede dispararse, el túnel puede empezar a conectar y la conexión muere en un certificado caducado o en un aviso que aparece en otra pantalla.
IPv6 crea una variante fácil de diagnosticar mal. Un nombre con ambas familias de direcciones puede responderse primero desde un registro AAAA, mientras que la lista de rutas del túnel solo lleva IPv4. Un navegador lo consigue, otro falla, y la lista de dominios es completamente inocente.
Prueba con una solicitud real, en este orden
Lee la política antes de hacer conjeturas. En macOS, sudo profiles show -type configuration imprime los perfiles instalados, incluido el payload VPN, scutil --nc list muestra el estado del servicio y scutil --nc show <service> imprime el diccionario on-demand que usa el sistema. En un iPhone o iPad supervisado, el mismo payload llega desde la consola de gestión o de un informe MDM. Los registros de red están disponibles con log stream --predicate 'subsystem == "com.apple.networkextension"' en macOS y a través de la consola del dispositivo cuando el teléfono está conectado.
Después prueba con un nombre de host que no se haya consultado antes en la sesión. Elige un nombre en la zona DNS del túnel que sepas que resuelve internamente, solicítalo una vez y observa si aparece el túnel. Ejecuta la misma consulta dos veces: el segundo intento ejercita la ruta de la caché, y la diferencia entre ambos te dice si el desencadenante es la resolución o el enrutamiento.
Una vez arriba el túnel, verifica las dos capas por separado. netstat -rn -f inet y netstat -rn -f inet6 muestran hacia dónde apunta cada prefijo, scutil --dns muestra el orden de los resolutores y qué interfaz posee cada uno, y nettop -m route muestra qué interfaz transportó los bytes. Si el túnel está arriba y el resolutor es correcto pero el recurso sigue fallando, deja de editar la regla; comprueba la autorización del servidor y la ruta de vuelta.
Cuando la regla es de otra persona
Si el túnel reaparece después de desconectarlo, la regla suele pertenecer a un perfil y no a una aplicación: una configuración enviada por MDM, un perfil personal sobrante o un perfil instalado por otro cliente. sudo profiles show -type configuration más una búsqueda de las claves on-demand lo acotará, y la ruta de eliminación es el perfil, no el interruptor de la barra de menús. Borrar la entrada del servicio o la aplicación deja la regla atrás, y la siguiente instalación la hereda de nuevo.
Una sola prueba resuelve la propiedad: desconecta, espera, solicita el nombre interno otra vez. Si el túnel vuelve, el desencadenante funciona como se diseñó y la pregunta abierta es quién lo gestiona y si ese alcance es el que quieres.
Antes de registrar esto como un error, recorre las mismas cinco comprobaciones: direcciones del resolutor del túnel presentes en el payload, un nombre que no estaba en caché, ninguna regla anterior que ya coincidiera, una ruta AAAA que cubra la lista de rutas y la aplicación dentro del alcance del túnel. Cuando las cinco se cumplen, la regla hace su trabajo y el fallo está más adelante en la ruta.