Come le regole di dominio di Apple VPN On Demand attivano un tunnel
Una regola di dominio decide solo quando si apre il tunnel. Come funziona la sonda DNS connect-if-needed, perché le rotte scelgono ancora il traffico e come testare il profilo.
Il tunnel si apre quando richiedi un nome interno e resta chiuso quando l’app successiva ne ha altrettanto bisogno. Non è un bug dell’app; è la forma di una regola di dominio. La configurazione on-demand di Apple descrive le condizioni per stabilire una connessione, e la forma dominio di quelle condizioni interroga il resolver di sistema prima che si muova un solo pacchetto. Due domande vengono confuse continuamente: quando il tunnel deve salire e cosa trasporta il tunnel una volta esistente. La prima è un trigger, la seconda è una politica di rotte e resolver, e un profilo di solito imposta entrambe nello stesso payload, per questo una regola di dominio corretta può comunque lasciarti sulla rete sbagliata.
Trigger e selezione del traffico stanno su livelli diversi
Una regola on-demand vive nel dizionario on-demand di un payload VPN: un elenco ordinato di regole, ciascuna con un’azione e un insieme di condizioni di corrispondenza. Il sistema le valuta quando cambia la connettività o quando qualcosa tenta di raggiungere la rete, e l’azione decide se il tunnel viene alzato, valutato, disconnesso o ignorato. Tutto questo avviene nel livello di rete della piattaforma, prima che la tua app abbia un socket.
Quello che segue è un gruppo separato di chiavi: le impostazioni IPv4 e IPv6 del tunnel, le sue rotte incluse ed escluse, gli indirizzi dei suoi server DNS e, su iOS e iPadOS, la mappatura per app che decide quali app possono usare il tunnel. Un profilo può abbinare un trigger ampio a una rotta stretta, o un trigger stretto a una rotta predefinita. Leggi solo una metà e l’altra sembrerà un malfunzionamento.
Ho un profilo di laboratorio che si connette ogni volta che viene richiesto qualcosa sotto un dominio interno, ma instrada solo una /16 nel tunnel. Fa esattamente ciò che dice il suo payload, ed è anche il tipo di profilo che genera ticket: le persone presumono che un tunnel connesso significhi che il loro traffico è dentro.
Cosa chiede davvero una regola di dominio al resolver
La forma dominio della regola, spesso chiamata connect-if-needed, non ispeziona i payload dei pacchetti né osserva gli URL. Quando un nome viene risolto, il sistema lo confronta con i domini della regola e, in caso di corrispondenza, chiede se quel nome può essere risolto tramite i server DNS forniti dal tunnel. Se risponde il resolver del tunnel, il nome conta come interno e la connessione parte. Se invece risponde il resolver locale, il nome viene trattato come esterno e non appare alcun tunnel. La panoramica di distribuzione di Apple lo descrive come rilevamento della rete seguito da valutazione della connessione.
Ne derivano due conseguenze. Il profilo deve indicare server DNS dentro il tunnel; una regola di dominio senza resolver del tunnel non ha nulla da confrontare, quindi la valutazione non può produrre la corrispondenza attesa. E la ricerca deve raggiungere il resolver di sistema. Un’app o un browser che esegue il proprio DNS cifrato, un’estensione che risponde localmente o una connessione a un indirizzo letterale non producono mai la risoluzione del nome che la regola aspettava. Uno dei pomeriggi più lunghi che ho passato è finito quando ho scoperto che il client davanti al tunnel usava DNS over HTTPS.
Anche la cache rimuove il trigger. Un nome già in cache può essere risolto senza la sonda che avrebbe avviato il tunnel, quindi una regola che funzionava ieri fallisce dopo un riavvio, o dopo che il tunnel è stato su per un po'. Su macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder reimposta lo stato; su iOS attivare e disattivare la modalità aereo o riavviare il dispositivo dà una tabula rasa paragonabile.
Ambito di corrispondenza: nomi, app e reti
La corrispondenza di dominio è un tipo tra diversi. Una regola può corrispondere anche al tipo di interfaccia (Wi-Fi, cellulare, Ethernet) e a uno specifico SSID, e le voci per app o dominio Safari legano un tunnel a un flusso di lavoro. Quel legame spiega l’esperienza strana in cui solo un’app si comporta diversamente da tutto il resto: le altre app sono fuori dall’ambito del tunnel, quindi continuano a usare il percorso locale anche quando l’icona del tunnel dice connesso.
L’ordine conta più di quanto la gente si aspetti. Le regole vengono valutate in sequenza e la prima che corrisponde fornisce l’azione, quindi una regola ampia connetti-su-qualsiasi-Wi-Fi posta sopra una regola di dominio stretta vincerà in silenzio e renderà la regola di dominio non testabile. Prima di riscrivere l’elenco dei domini, conferma che nessuna regola precedente abbia già corrisposto.
Ecco perché always-on non è solo una regola on-demand più severa. L’applicazione di always-on è una modalità di distribuzione separata con i propri requisiti di supervisione e gestione; mantiene un tunnel aperto invece di reagire a un nome. Se ciò che ti serve è un tunnel che non cade mai, una regola di dominio è lo strumento sbagliato.
Modalità di errore che imitano una regola rotta
La maggior parte delle segnalazioni che una regola di dominio non funziona cade in uno di cinque punti, e solo l’ultimo è il testo della regola.
| 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 |
I portali captive meritano una riga propria, perché il Wi-Fi di hotel e aeroporti intercetta proprio la ricerca da cui dipende la regola. Finché il portale non ammette il dispositivo, il server DNS del tunnel è irraggiungibile, la sonda fallisce e l’errore sembra un dominio scritto male. L’autenticazione è l’altro caso silenzioso: la regola può scattare, il tunnel può iniziare a connettersi e la connessione muore su un certificato scaduto o su un prompt che appare su un altro display.
IPv6 crea una variante facile da diagnosticare male. Un nome con entrambe le famiglie di indirizzi può essere risolto prima da un record AAAA, mentre l’elenco delle rotte del tunnel porta solo IPv4. Un browser riesce, un altro fallisce, e l’elenco dei domini è del tutto innocente.
Prova con una richiesta reale, in questo ordine
Leggi la politica prima di indovinare. Su macOS sudo profiles show -type configuration stampa i profili installati incluso il payload VPN, scutil --nc list mostra lo stato del servizio e scutil --nc show <service> stampa il dizionario on-demand che il sistema usa. Su un iPhone o iPad supervisionato lo stesso payload arriva dalla console di gestione o da un report MDM. I log di rete sono disponibili con log stream --predicate 'subsystem == "com.apple.networkextension"' su macOS e tramite la console del dispositivo quando il telefono è collegato.
Poi prova con un nome host che non è stato interrogato prima nella sessione. Scegli un nome nella zona DNS del tunnel che sai risolversi internamente, richiedilo una volta e osserva se il tunnel appare. Esegui la stessa ricerca due volte: il secondo tentativo esercita il percorso della cache, e la differenza tra i due ti dice se il trigger è la risoluzione o l’instradamento.
Una volta che il tunnel è su, verifica i due livelli separatamente. netstat -rn -f inet e netstat -rn -f inet6 mostrano dove punta ogni prefisso, scutil --dns mostra l’ordine dei resolver e quale interfaccia possiede ciascun resolver, e nettop -m route mostra quale interfaccia ha trasportato i byte. Se il tunnel è su e il resolver è corretto ma la risorsa continua a fallire, smetti di modificare la regola; controlla l’autorizzazione lato server e la rotta di ritorno.
Quando la regola è di qualcun altro
Se il tunnel riappare dopo che l’hai disconnesso, la regola di solito appartiene a un profilo e non a un’app: una configurazione spinta via MDM, un profilo personale rimasto o un profilo installato da un altro client. sudo profiles show -type configuration più una ricerca delle chiavi on-demand lo circoscriverà, e il percorso di rimozione è il profilo, non l’interruttore nella barra dei menu. Eliminare la voce del servizio o l’app lascia la regola, e l’installazione successiva la eredita di nuovo.
Un solo test risolve la proprietà: disconnetti, aspetta, richiedi di nuovo il nome interno. Se il tunnel torna, il trigger funziona come progettato e la domanda aperta è chi lo gestisce e se quell’ambito è quello che vuoi.
Prima di segnalarlo come bug, passa attraverso gli stessi cinque controlli: indirizzi del resolver del tunnel presenti nel payload, un nome che non era in cache, nessuna regola precedente già corrispondente, un percorso AAAA coperto dall’elenco delle rotte e l’app dentro l’ambito del tunnel. Quando tutti e cinque valgono, la regola fa il suo lavoro e il guasto è più avanti lungo il percorso.