Com les regles de domini d’Apple VPN On Demand obren un túnel
Una regla de domini només decideix quan s’obre el túnel. Com funciona la sonda DNS connect-if-needed, per què les rutes encara trien el trànsit i com provar el perfil.
El túnel s’obre quan sol·liciteu un nom intern i queda tancat quan la següent aplicació el necessita igual de desesperadament. Això no és un error de l’aplicació; és la forma d’una regla de domini. La configuració on-demand d’Apple descriu condicions per fer una connexió, i la forma de domini d’aquestes condicions fa una pregunta al resolutor del sistema abans que es mogui un sol paquet. Dues preguntes es confonen constantment: quan ha de pujar el túnel i què transporta el túnel un cop existeix. La primera és un disparador, la segona és una política de rutes i resolutor, i un perfil normalment estableix les dues al mateix payload, per això una regla de domini correcta us pot deixar igualment a la xarxa equivocada.
El disparador i la selecció de trànsit són a capes diferents
Una regla on-demand viu al diccionari on-demand d’un payload VPN: una llista ordenada de regles, cadascuna amb una acció i un conjunt de condicions de coincidència. El sistema les avalua quan canvia la connectivitat o quan alguna cosa intenta arribar a la xarxa, i l’acció decideix si el túnel s’aixeca, s’avalua, es desconnecta o s’ignora. Tot això passa a la capa de xarxa de la plataforma, abans que la vostra aplicació tingui un socket.
El que passa després és un grup separat de claus: la configuració IPv4 i IPv6 del túnel, les seves rutes incloses i excloses, les adreces dels servidors DNS i, a iOS i iPadOS, el mapatge per aplicació que decideix quines aplicacions poden usar el túnel. Un perfil pot combinar un disparador ampli amb una ruta estreta, o un disparador estret amb una ruta per defecte. Llegiu només una meitat i l’altra semblarà un mal funcionament.
Tinc un perfil de laboratori que es connecta sempre que se sol·licita qualsevol cosa sota un domini intern, però només encamina una /16 cap al túnel. Fa exactament el que diu el seu payload, i també és el tipus de perfil que genera tiquets: la gent assumeix que un túnel connectat significa que el seu trànsit hi és dins.
Què pregunta realment una regla de domini al resolutor
La forma de domini de la regla, sovint anomenada connect-if-needed, no inspecciona els payloads dels paquets ni observa URL. Quan es resol un nom, el sistema el compara amb els dominis de la regla i, si coincideix, pregunta si aquell nom es pot resoldre a través dels servidors DNS que proporciona el túnel. Si respon el resolutor del túnel, el nom compta com a intern i s’inicia la connexió. Si en canvi respon el resolutor local, el nom es tracta com a extern i no apareix cap túnel. La visió general de desplegament d’Apple ho descriu com a detecció de xarxa seguida d’avaluació de connexió.
Se’n deriven dues conseqüències. El perfil ha de nomenar servidors DNS dins del túnel; una regla de domini sense resolutor de túnel no té res a comparar, així que l’avaluació no pot produir la coincidència que espereu. I la consulta ha d’arribar al resolutor del sistema. Una aplicació o un navegador que executa el seu propi DNS xifrat, una extensió que respon localment o una connexió a una adreça literal mai no produeixen la resolució de nom que la regla esperava. Una de les tardes més llargues que he passat va acabar quan vaig descobrir que el client davant del túnel feia servir DNS over HTTPS.
La memòria cau també elimina el disparador. Un nom que ja és a la memòria cau es pot respondre sense la sonda que hauria iniciat el túnel, així que una regla que ahir funcionava falla després d’un reinici o després que el túnel hagi estat aixecat una estona. A macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder reinicia l’estat; a iOS, activar i desactivar el mode avió o reiniciar el dispositiu us dona un full net comparable.
Abast de coincidència: noms, aplicacions i xarxes
La coincidència de domini és un tipus entre diversos. Una regla també pot coincidir amb el tipus d’interfície (Wi-Fi, mòbil, Ethernet) i una SSID concreta, i les entrades per aplicació o domini de Safari lliguen un túnel a un flux de treball. Aquest lligam explica l’experiència estranya en què només una aplicació es comporta diferent de tota la resta: les altres aplicacions són fora de l’abast del túnel, així que continuen usant el camí local fins i tot quan la icona del túnel diu connectat.
L’ordre importa més del que la gent espera. Les regles s’avaluen en seqüència i la primera que coincideix proporciona l’acció, així que una regla àmplia de connecta-a-qualsevol-Wi-Fi col·locada per sobre d’una regla de domini estreta guanyarà en silenci i farà que la regla de domini no es pugui provar. Abans de reescriure la llista de dominis, confirmeu que cap regla anterior ja ha coincidit.
Per això també always-on no és només una regla on-demand més estricta. L’aplicació d’always-on és un mode de desplegament separat amb els seus propis requisits de supervisió i gestió; manté un túnel obert en lloc de reaccionar a un nom. Si el que necessiteu és un túnel que no caigui mai, una regla de domini és l’eina equivocada.
Maneres de fallar que imiten una regla trencada
La majoria d’informes que una regla de domini no funciona cauen en un de cinc llocs, i només l’últim és el text 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 |
Els portals captius mereixen la seva pròpia línia, perquè el Wi-Fi d’hotels i aeroports intercepta precisament la consulta de la qual depèn la regla. Fins que el portal admet el dispositiu, el servidor DNS del túnel és inabastable, la sonda falla i el fracàs sembla un domini mal escrit. L’autenticació és l’altre cas silenciós: la regla pot disparar-se, el túnel pot començar a connectar i la connexió mor en un certificat caducat o en un avís que apareix en una altra pantalla.
IPv6 crea una variant fàcil de diagnosticar malament. Un nom amb les dues famílies d’adreces es pot respondre primer des d’un registre AAAA, mentre que la llista de rutes del túnel només porta IPv4. Un navegador ho aconsegueix, un altre falla, i la llista de dominis és completament innocent.
Proveu amb una sol·licitud real, en aquest ordre
Llegiu la política abans de fer conjectures. A macOS, sudo profiles show -type configuration imprimeix els perfils instal·lats, inclòs el payload VPN, scutil --nc list mostra l’estat del servei i scutil --nc show <service> imprimeix el diccionari on-demand que fa servir el sistema. En un iPhone o iPad supervisat, el mateix payload arriba de la consola de gestió o d’un informe MDM. Els registres de xarxa estan disponibles amb log stream --predicate 'subsystem == "com.apple.networkextension"' a macOS i a través de la consola del dispositiu quan el telèfon està connectat.
Després proveu amb un nom d’amfitrió que no s’hagi consultat abans en la sessió. Trieu un nom a la zona DNS del túnel que sapigueu que es resol internament, sol·liciteu-lo una vegada i observeu si apareix el túnel. Executeu la mateixa consulta dues vegades: el segon intent exercita el camí de la memòria cau, i la diferència entre tots dos us diu si el disparador és la resolució o l’encaminament.
Un cop el túnel és a dalt, verifiqueu les dues capes per separat. netstat -rn -f inet i netstat -rn -f inet6 mostren on apunta cada prefix, scutil --dns mostra l’ordre dels resolutors i quina interfície posseeix cada resolutor, i nettop -m route mostra quina interfície ha portat els bytes. Si el túnel és a dalt i el resolutor és correcte però el recurs encara falla, atureu l’edició de la regla; comproveu l’autorització del servidor i la ruta de tornada.
Quan la regla és d’una altra persona
Si el túnel reapareix després de desconnectar-lo, la regla normalment pertany a un perfil i no a una aplicació: una configuració enviada per MDM, un perfil personal sobrant o un perfil instal·lat per un altre client. sudo profiles show -type configuration més una cerca de les claus on-demand ho acotarà, i el camí de supressió és el perfil, no l’interruptor de la barra de menús. Esborrar l’entrada del servei o l’aplicació deixa la regla enrere, i la instal·lació següent l’hereta de nou.
Una sola prova resol la propietat: desconnecteu, espereu, sol·liciteu el nom intern de nou. Si el túnel torna, el disparador funciona com estava dissenyat i la pregunta oberta és qui el gestiona i si aquest abast és el que voleu.
Abans de presentar això com un error, passeu per les mateixes cinc comprovacions: adreces del resolutor del túnel presents al payload, un nom que no era a la memòria cau, cap regla anterior que ja hagués coincidit, un camí AAAA que la llista de rutes cobreixi, i l’aplicació dins de l’abast del túnel. Quan les cinc es compleixen, la regla fa la seva feina i la fallada és més enllà al llarg del camí.