Esaminare il comportamento delle query DNS e della risoluzione dei nomi di dominio
Sommario
Introduzione
In questo documento viene descritto come i sistemi operativi client gestiscono le query DNS e gli effetti sulla risoluzione dei nomi di dominio tramite Cisco IOS® Secure Client.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware. Gli esempi di laboratorio utilizzano le policy di gruppo ASA/FTD Secure Firewall e Cisco Secure Client su Windows, macOS, Linux e Apple iOS.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
DNS diviso e standard
In questo documento viene illustrato come i sistemi operativi client gestiscono le query DNS e gli effetti sulla risoluzione dei nomi di dominio quando si utilizza Cisco Secure Client (in precedenza Cisco AnyConnect) con il tunneling completo o con split. Gli headend VPN discussi includono Cisco Secure Firewall ASA e FTD (in precedenza ASA); le impostazioni dei criteri di gruppo, ad esempio split-dns, dns-server e split-tunnel-all-dns, vengono applicate a entrambi, a meno che non sia specificato diversamente.
Se una sezione fa riferimento in modo esplicito a versioni client precedenti, viene applicato il comportamento descritto per Secure Client 4.2 e versioni successive (incluse le versioni correnti di Secure Client 5.x). Cisco AnyConnect 4.x ha raggiunto la fine del ciclo di vita; eseguire la migrazione a Cisco Secure Client per le funzionalità DNS e di tunneling supportate.
Il comportamento della risoluzione DNS dipende da tre fattori:
- Criterio VPN DNS: Configurato sull'headend (DNS suddiviso, DNS "tunnel tutto" o DNS standard)
- Modalità tunneling ripartito: Tunnel-all, split-include o split-exclude
- Sistema operativo client: Architettura del resolver DNS (per interfaccia e globale)
Quando si esegue il comando split-include tunneling, sono disponibili le tre opzioni DNS seguenti nei Criteri di gruppo:
| Modalità |
Descrizione |
|---|---|
| Dividi DNS | Le query DNS che corrispondono ai nomi di dominio configurati nell'headend (split-dns) vengono inviate tramite il tunnel ai server DNS VPN (dns-server). Tutte le altre query utilizzano il resolver del sistema operativo del client e i server DNS della scheda fisica. |
| Tunnel-all-DNS | È consentito solo il traffico DNS verso i server DNS definiti dall'headend. Configurato con split-tunnel-all-dns enable nei Criteri di gruppo. |
| DNS standard | Tutte le query DNS vengono innanzitutto inviate ai server DNS VPN definiti dall'headend. In caso di risposta negativa (NXDOMAIN o nessuna risposta), il resolver può anche provare a utilizzare i server DNS sulla scheda fisica. |
Nota: Il comando split-tunnel-all-dns è stato implementato per la prima volta in ASA versione 8.2(5). Prima di tale versione, erano disponibili solo DNS divisi o DNS standard. In tutti i casi, le query DNS definite per lo spostamento nel tunnel vengono passate a qualsiasi server DNS definito dall'headend. Se nell'headend non è definito alcun server DNS, le impostazioni DNS per il tunnel sono vuote.
Se i DNS divisi non sono definiti, tutte le query DNS vengono inviate ai server DNS definiti dall'headend (in base al comportamento specifico del sistema operativo descritto più avanti in questo documento). Tuttavia, i comportamenti descritti in questo documento possono variare a seconda del sistema operativo.
Test del DNS — Importante
Nota: Evitare di utilizzare NSLookup o dig durante il test della risoluzione dei nomi sul client. Usare un browser Web o eseguire il comando ping. NSLookup e dig non utilizzano lo stub del resolver DNS del sistema operativo come la maggior parte delle applicazioni. Secure Client non impone ogni richiesta DNS tramite un'interfaccia specifica; consente o rifiuta le richieste basate su criteri DNS divisi e DNS "tunnel all".
Per osservare il comportamento corretto del failover, eseguire il test solo con le applicazioni che si basano sul resolver DNS del sistema operativo nativo (browser, ping e la maggior parte delle applicazioni aziendali). Gli strumenti che eseguono la propria risoluzione DNS (NSLookup, dig e alcune app personalizzate) possono mostrare errori fuorvianti anche quando il client funziona correttamente.
DNS suddiviso tra True e Best Effort
AnyConnect release 2.4 ha introdotto il fallback del DNS suddiviso (best-fort split DNS), che non è un DNS suddiviso vero e proprio ed è stato trovato anche nel client IPsec legacy.
Comportamento massimo sforzo (fallback):
- Se la richiesta corrisponde a un dominio DNS suddiviso, Secure Client consente di eseguire il tunneling della richiesta all'headend.
- Se il server DNS VPN non è in grado di risolvere il nome host, il resolver DNS del sistema operativo continua e può inviare la stessa query a un server DNS sull'interfaccia fisica.
- Se la richiesta non corrisponde ad alcun dominio DNS suddiviso, il client sicuro non la esegue. È possibile sintetizzare una risposta in modo che il resolver esegua il fallback ai server DNS dell'interfaccia fisica.
Per questo motivo la funzionalità legacy è denominata fallback DNS per il tunneling suddiviso, che non è un DNS suddiviso vero e proprio. Secure Client assicura che solo le query di domini suddivisi corrispondenti entrino nel tunnel, ma si basa comunque sul comportamento del sistema di risoluzione del sistema operativo per la risoluzione finale.
Problemi di sicurezza: Un nome di dominio privato può perdere dati in un server DNS pubblico quando il server DNS VPN restituisce NXDOMAIN o non riesce a risolvere il problema; e il resolver ritenta la scheda fisica.
DNS suddiviso vero: ID bug Cisco CSCtn14578
Risolto su Microsoft Windows in AnyConnect 3.0(4235) e mantenuto in Secure Client (4.2+):
- Le query per i domini DNS divisi configurati sono consentite solo tramite il percorso VPN (server DNS del tunnel/scheda VPN, a seconda della piattaforma e della versione).
- Tutte le altre query sono consentite solo tramite server DNS non VPN (scheda fisica).
Nota: Solo gli utenti Cisco registrati possono accedere agli strumenti di bug interni di Cisco e alle informazioni dettagliate sui bug.
DNS "tunnel-all" e "tunnel-all"
Quando il tunneling suddiviso è disabilitato (configurazione tunnel tutto), il traffico DNS viene consentito esclusivamente attraverso il tunnel.
La configurazione tunnel-all-DNS (split-tunnel-all-dns abilitato nei Criteri di gruppo) invia tutte le ricerche DNS attraverso il tunnel, mentre è configurata anche una qualche forma di tunneling suddiviso e il traffico DNS è autorizzato esclusivamente tramite l'interfaccia del tunnel.
Questo è coerente tra le piattaforme con un'avvertenza su Microsoft Windows, quando il DNS tunnel-all o tunnel-all è configurato, Secure Client consente il traffico DNS solo verso i server DNS configurati sul gateway sicuro (applicato alla scheda VPN). Questo miglioramento della sicurezza è stato implementato con il DNS con divisione effettiva. Se il problema persiste (ad esempio, l'aggiornamento/la registrazione DNS deve raggiungere i server DNS non VPN), attenersi alla seguente procedura:
- Se la configurazione corrente è tunnel-all, abilitare il tunneling split-exclude. È possibile utilizzare qualsiasi rete con esclusione della divisione host singolo, ad esempio un indirizzo locale del collegamento.
- Verificare che tunnel-all-DNS non sia abilitato in Criteri di gruppo (split-tunnel-all-dns disabilitato).
Tunnel-all-DNS e Cisco Secure Client Umbrella Module
Quando il tunneling diviso e il tunnel all-DNS sono entrambi abilitati, il DNS viene intercettato a livello di kernel e bloccato se non esce dall'interfaccia VPN corretta. Il modulo Secure Client Umbrella (in precedenza AnyConnect Roaming Security) può essere interessato dalle reti in cui il DNS crittografato non è disponibile. Infatti, il modulo può provare a utilizzare il DNS standard tramite l'interfaccia LAN, mentre il DNS tunnel all richiede il DNS tramite la VPN.
Per impostazione predefinita, il modulo Umbrella utilizza il DNS crittografato (porta UDP 443), che in genere non è bloccato da tunnel-all-DNS. Il problema si verifica principalmente quando la crittografia non è disponibile e viene utilizzato il DNS semplice.
Consiglio: Aggiungere gli indirizzi del resolver Cisco Umbrella all'elenco di split-include se si utilizza tunnel-all-DNS con il modulo Umbrella. In alternativa, fare riferimento al documento Enable Tunnel All DNS for Secure Client with Umbrella Module (ID documento: 224809).
Problema di prestazioni DNS risolto in AnyConnect versione 3.0 (4235)
Questo problema relativo a Microsoft Windows è più frequente nelle seguenti condizioni:
- Configurazione del router principale in cui i server DNS e DHCP condividono lo stesso indirizzo IP (Secure Client crea una route necessaria al server DHCP).
- Numerosi suffissi/domini DNS nei Criteri di gruppo.
- Una configurazione completa.
- Poiché la risoluzione dei nomi utilizza un nome host non qualificato, il resolver tenta di utilizzare più suffissi DNS in tutti i server DNS disponibili.
- Il client DNS nativo tenta di inviare query DNS tramite la scheda fisica, che il client protetto blocca in tunnel-all.
Ciò può causare ritardi significativi nella risoluzione dei nomi, in particolare quando l'headend esegue il push di molti suffissi DNS. Il resolver deve scorrere i suffissi e i server fino a quando non riceve una risposta positiva.
Il problema è stato risolto in AnyConnect 3.0(4235) e versioni successive di Secure Client. Per ulteriori informazioni, fare riferimento all'ID bug Cisco CSCtq02141 e all'ID bug Cisco CSCtn14578.
Nota: Solo gli utenti Cisco registrati possono accedere agli strumenti di bug interni di Cisco.
Soluzioni (se non è possibile un aggiornamento)
Abilitare il tunneling split-exclude per un indirizzo IP in modo che il DNS locale possa utilizzare la scheda fisica. È improbabile che un indirizzo della subnet locale del collegamento 169.254.0.0/16 venga utilizzato come traffico verso tali indirizzi attraverso la VPN.
Dopo aver abilitato il tunneling split-exclude, abilitare l'accesso LAN locale sul profilo o sul client e disabilitare tunnel-all-DNS. Questo è un esempio di configurazione ASA/FTD:
access-list acl_linklocal_169.254.1.1 standard permit host 169.254.1.1
group-policy gp_access-14 attributes
split-tunnel-policy excludespecified
split-tunnel-network-list value acl_linklocal_169.254.1.1
split-tunnel-all-dns disable
exit
XML profilo client:
<LocalLanAccess UserControllable="true">true</LocalLanAccess>
È possibile abilitare questa funzionalità anche nell'interfaccia utente Secure Client: Preferenze → Abilita Consenti accesso locale (LAN) quando si utilizza VPN
- Utilizzare nomi di dominio completi (FQDN) anziché nomi host non qualificati.
- Utilizzare un indirizzo IP diverso per il server DNS nell'interfaccia fisica (diverso da DHCP nella stessa subnet).
DNS con tunneling ripartito su sistemi operativi client diversi
Sistemi operativi client diversi gestiscono il DNS in modo diverso con il tunneling suddiviso (senza DNS suddiviso) per Secure Client; in questa sezione vengono descritte tali differenze.
Microsoft Windows (Windows 10 e Windows 11)
In Windows, le impostazioni DNS si riferiscono all'interfaccia di rete. Con il tunneling suddiviso, le query DNS possono eseguire il fallback ai server DNS della scheda fisica dopo che si sono verificati errori nella scheda del tunnel VPN. Se si utilizza il tunneling suddiviso senza DNS suddiviso, la risoluzione interna ed esterna può funzionare come il resolver può eseguire il fallback ai server DNS esterni. Si è verificata una modifica significativa in Secure Client for Windows nella versione 4.2 dopo la correzione dell'ID bug Cisco CSCuf07885. Questo comportamento non è modificato in Secure Client 5.x.
Nota: Solo gli utenti Cisco registrati possono accedere agli strumenti di bug interni di Cisco.
Configurazione completa del tunnel (e tunneling ripartito con tunnel DNS completo abilitato)
Pre-Secure Client 4.2 (AnyConnect 4.1 e versioni precedenti):
- Sono consentite solo le richieste DNS ai server DNS configurati in Criteri di gruppo (server DNS tunnel).
- Il driver Secure Client risponde a tutte le altre richieste senza un nome di questo tipo.
- La risoluzione DNS può utilizzare solo server DNS tunnel.
Secure Client 4.2 e versioni successive:
- Le richieste DNS a qualsiasi server DNS sono consentite se provengono dalla scheda VPN e vengono inviate attraverso il tunnel.
- Tutte le altre richieste non ricevono tale nome; solo tramite il tunnel VPN.
- Prima dell'ID bug Cisco CSCuf07885, i server DNS di destinazione con restrizioni Secure Client. In seguito a questa correzione, vengono limitate le schede di rete che possono avviare richieste DNS.
Configurazione split-include (DNS tunnel tutto disabilitato, DNS non diviso)
Il driver Secure Client non interferisce con il resolver DNS nativo. La risoluzione è conforme all'ordine delle schede di rete; Secure Client è l'adattatore preferito quando la VPN è connessa.
Una query DNS viene prima inviata tramite il tunnel; se non risolto, il resolver può provare l'interfaccia pubblica. L'elenco degli accessi con inclusione separata deve includere la subnet che copre i server DNS del tunnel nelle versioni precedenti alla 4.2. A partire da Secure Client 4.2, le route host per i server DNS del tunnel vengono aggiunte automaticamente come reti con inclusione divisa (route sicure), pertanto l'ACL con inclusione divisa non richiede più subnet di server DNS del tunnel esplicite.
Configurazione split-exclude (DNS tunnel tutto disattivato, DNS diviso non disattivato)
Lo stesso comportamento del resolver della funzione split-include, prima il tunnel, poi il fallback dell'interfaccia pubblica. L'elenco degli accessi split-exclude non deve includere la subnet che copre i server DNS del tunnel. A partire da Secure Client 4.2, le route host automatiche per i server DNS del tunnel impediscono la configurazione errata di split-exclude comune.
Split-DNS (Tunnel-all-DNS disabilitato, Split-include configurato)
Split-DNS in Windows richiede il tunneling split-include (specificato tunneling split-tunnel-policy). Non supporta criteri tunnel split-exclude-only per la configurazione split-DNS.
Pre-Secure Client 4.2:
- Query su domini DNS divisi: Autorizzato a eseguire il tunnel solo dei server DNS. se inviato ad altri server, questo nome non è disponibile.
- Query su dominio DNS non suddiviso: Consentito solo ad altri server DNS; nessun nome di questo tipo se tentato tramite tunnel.
Secure Client 4.2 e versioni successive (DNS suddiviso vero in Windows):
- Query su domini DNS divisi: Autorizzato a qualsiasi server DNS solo se proviene dalla scheda VPN. Le query dall'interfaccia pubblica non ricevono questo nome per forzare l'utilizzo del tunnel.
- Query su dominio DNS non suddiviso: Autorizzato a qualsiasi server DNS solo se proviene dalla scheda fisica. Le query dalla scheda VPN non ricevono tale nome per forzare la risoluzione dell'interfaccia pubblica.
Split-DNS con tunneling split-exclude (Secure Client 5.x)
La documentazione per l'amministratore Secure Client 5.x aggiunge il DNS suddiviso per le configurazioni con split-exclude. Fare riferimento alla Secure Client 5.x Administrator Guide — Configure Split DNS for Split Exclude Tunneling per i requisiti di headend e criteri. Le regole di imposizione a livello di sistema operativo sono ancora valide dopo la divisione del DNS.
DNS crittografato (DoH/DoT) in Windows
Le applicazioni o le funzionalità del sistema operativo che utilizzano DNS su HTTPS (DoH) o DNS su TLS (DoT) possono ignorare il percorso del resolver di stub di Windows filtrato da Secure Client. Se la suddivisione del DNS sembra avere esito negativo per applicazioni specifiche, ma funziona in un browser, verificare se tali applicazioni utilizzano DNS crittografati o personalizzati. Per i test standard con split-DNS è necessario utilizzare il sistema di risoluzione del sistema operativo (browser, ping) e non NSLookup/dig.
macOS
In macOS, le impostazioni DNS sono globali (non per interfaccia). Se si utilizza il tunneling suddiviso senza DNS suddiviso, le query DNS spesso non possono raggiungere i server DNS all'esterno del tunnel come previsto, è possibile risolvere solo i nomi interni e non i nomi esterni tramite il percorso pubblico. Questa condizione è documentata nell'ID bug Cisco CSCtf20226 e nell'ID bug Cisco CSCtz86314.
Soluzioni:
- Specificare l'indirizzo IP di un server DNS esterno in Criteri di gruppo e utilizzare gli FQDN per le query interne.
- Se i nomi esterni possono essere risolti tramite il tunnel, disabilitare la suddivisione del DNS in Avanzate > Tunneling rimuovendo i nomi DNS dai criteri di gruppo e utilizzare gli FQDN per le query interne.
Lo split DNS su macOS è supportato da AnyConnect 3.1 e versioni successive, a condizione che:
- Split DNS abilitato per entrambi i protocolli IP (richiede ASA 9.0+/FTD equivalente) oppure
- Suddividi DNS abilitato per un protocollo IP e Client Bypass Protocol abilitato per l'altro senza pool di indirizzi per il protocollo ignorato (o senza pool IPv6 nelle versioni ASA precedenti alla 9.0).
Nota: Secure Client non gestisce principalmente la risoluzione dei nomi tramite /etc/resolv.conf su macOS; vengono configurate le impostazioni DNS a livello di sistema operativo. macOS può mantenere resolv.conf aggiornato per la compatibilità. Eseguire scutil —dns per visualizzare la configurazione DNS effettiva.
Configurazione completa del tunnel (e tunneling ripartito con tunnel DNS completo abilitato)
Quando Secure Client è connesso, nella configurazione DNS del sistema rimangono solo i server DNS del tunnel. le richieste vengono inoltrate solo ai server DNS del tunnel.
Dividi-include/Dividi-escludi (Tunnel-all-DNS disabilitato, no Split-DNS)
Secure Client non interferisce con il resolver nativo. I server DNS del tunnel sono preferiti rispetto ai resolver pubblici, pertanto il primo tentativo di query supera il tunnel. Poiché il DNS è globale in macOS, le query non sempre utilizzano in modo affidabile il DNS pubblico all'esterno del tunnel (ID bug Cisco: CSCtf20226).
A partire da Secure Client 4.2, le route host per i server DNS del tunnel vengono aggiunte automaticamente come route sicure.
Split-DNS (Tunnel-all-DNS disabilitato, Split-include configurato)
True split DNS (simile a Windows) viene applicato quando:
- Split-DNS è abilitato sia per IPv4 che per IPv6 oppure
- Split-DNS è abilitato per un protocollo e non esiste alcun pool di indirizzi client per l'altro protocollo.
Se ha valore True, i domini DNS divisi corrispondenti vengono risolti solo tramite il tunnel e non trapelano ai resolver esterni.
Se split-DNS è abilitato solo per un protocollo e un indirizzo client è assegnato per l'altro protocollo, viene applicato solo il fallback DNS per il tunneling suddiviso: Secure Client consente query corrispondenti tramite il tunnel (è possibile rifiutare altre query per forzare il failover), ma non è in grado di impedire completamente la fuoriuscita di query su domini DNS suddivisi inviate in chiaro tramite la scheda pubblica.
Supporto piattaforma (Secure Client admin guide): Il DNS con split completo è supportato su Windows e macOS. Linux ha un supporto limitato (vedere la sezione Linux).
Linux
Configurazione completa del tunnel (e tunneling ripartito con tunnel DNS completo abilitato)
Quando Secure Client è connesso, nella configurazione DNS del sistema vengono gestiti solo i server DNS di tunnel.
Dividi-include/Dividi-escludi (Tunnel-all-DNS disabilitato, No Split-DNS)
Secure Client non interferisce con il resolver nativo. Server DNS tunnel preferiti; il tentativo di risoluzione iniziale supera il tunnel.
Split-DNS (Tunnel-all-DNS disabilitato, Split-include configurato)
Se split-DNS è abilitato, solo il fallback DNS per il tunneling suddiviso viene imposto su Linux:
- Secure Client consente query su domini DNS suddivisi tramite il tunnel.
- È possibile che altre query ricevano un rifiuto per incoraggiare il failover al DNS pubblico.
- Secure Client non è in grado di applicare completamente le query split-DNS-domain, in quanto non vengono mai inviate in chiaro tramite la scheda pubblica.
Nella guida per l'amministratore di Secure Client sono riportate informazioni sulla limitazione della suddivisione del DNS in Linux: solo le richieste DNS con tunneling sono completamente soggette ai criteri DNS suddivisi; alcune query esterne al tunnel non possono essere conformi ai criteri DNS suddivisi.
VM e contenitori Linux
Secure Client supporta un attributo personalizzato tunnel da qualsiasi origine, pertanto i pacchetti con qualsiasi indirizzo di origine possono essere instradati in modalità split-include o split-exclude all'interno di istanze VM o contenitori Docker. Per i dettagli sulla configurazione, consultare la Secure Client 5.x Administrator Guide (Guida dell'amministratore Secure Client 5.x).
Apple iOS (iPhone e iPad)
Il comportamento di iOS è diverso da macOS e non è identico a Windows. Se il tunneling suddiviso è configurato senza DNS suddiviso, le query DNS utilizzano in genere il server DNS globale definito per il dispositivo e non lo stesso modello di fallback di Windows.
Impatto pratico: Le voci di dominio DNS suddivise sono spesso necessarie per una risoluzione affidabile dei nomi interni quando si utilizza il tunneling suddiviso senza DNS suddiviso.
Correzione cronologica: ID bug Cisco CSCtq09624 - (AnyConnect per iOS 2.5.4038 e versioni successive). L'attuale Secure Client per iOS soddisfa gli stessi requisiti generali; configurare il DNS suddiviso per i domini interni quando si utilizza split-include/split e lo si esclude senza utilizzare il fallback di tipo Windows.
Nota: Le query DNS iOS ignorano i domini .local (ID bug Cisco CSCts89292).
Apple considera questo comportamento come un comportamento progettato; non si prevede una risoluzione .local tramite DNS split standard su iOS. Su iOS, il comportamento split-DNS dei client sicuri differisce anche da altre piattaforme quando il tunneling suddiviso è combinato con alcune configurazioni di elenchi split-DNS. Per informazioni sulle combinazioni di criteri specifiche di iOS (split-dns none, default-domain e così via), fare riferimento alla sezione della guida per l'amministratore di Secure Client, "Split DNS Resolution Behavior with Split Tunnel".
Tunneling ripartito dinamico e DNS (Secure Client 4.5+)
Il tunneling con split dinamico risolve i nomi di dominio completi (FQDN) al momento della connessione o su richiesta e regola il routing e i filtri per il traffico ai domini specificati. Questo è incluso o escluso dal tunnel senza elenchi IP statici.
| Funzionalità | Descrizione |
|---|---|
| Esclusione divisione dinamica | I domini (example.com) vengono esclusi dal tunnel in fase di esecuzione quando le applicazioni risolvono tali nomi. |
| Divisione dinamica | I domini vengono inclusi in modo dinamico nel tunnel. |
| Divisione dinamica migliorata | Elenchi di domini di inclusione/esclusione combinati con regole di precedenza, ad esempio escludendo example.com, ma includendo mail.example.com. |
Il tunneling con split dinamico utilizza la risoluzione DNS per guidare le modifiche del routing. È configurato tramite attributi personalizzati Secure Client sull'headend (ad esempio, domini dynamic-split-exclude, domini dynamic-split-include).
Il tunneling con split dinamico si applica ai criteri tunnel-all e split-exclude (esclusione dinamica) o split-include (inclusione dinamica). Non sostituisce i criteri DNS suddivisi, tuttavia, li integra: il DNS diviso controlla quali query sono sottoposte a tunneling; il tunneling con split dinamico controlla il traffico IP che viene tunneling in base ai nomi risolti. Fare riferimento ai dettagli della configurazione: Configure Dynamic Split Tunneling e alla Guida dell'amministratore di Secure Client 5.x.
Failover split-exclude (Secure Client 5.x): L'attributo personalizzato facoltativo SplitExcludeFailoverEnabled instrada il traffico attraverso la VPN quando il percorso pubblico non dispone di connettività per le destinazioni split-exclude. Per l'impostazione degli attributi personalizzati, consultare la guida dell'amministratore.
Versioni cronologiche client (riferimento)
La tabella seguente si applica solo alle distribuzioni legacy che ancora eseguono client obsoleti:
| Version | Rilevanza |
|---|---|
| AnyConnect 2.4 | È stato introdotto il fallback DNS di tipo Best-FFORT Split |
| AnyConnect 2.5 (iOS) | ID bug Cisco: Allineamento DNS CSCtq09624 iOS |
| AnyConnect 3.0(4235) | True split DNS su Windows; Correzioni alle prestazioni DNS |
| AnyConnect 3.1 (macOS) | Supporto DNS diviso con condizioni IPv4/IPv6 |
| AnyConnect 4.2 | ID bug Cisco: CSCuf07885 applicazione basata su adattatore; route automatiche host DNS del tunnel |
Distribuire Secure Client 5.x su tutte le piattaforme supportate per le correzioni e le funzionalità correnti.
Informazioni correlate ai bug
Nota: Solo gli utenti Cisco registrati possono accedere agli strumenti di bug interni di Cisco.
- ID bug Cisco: CSCtn14578 - True split DNS (non fallback) - Windows, 3.0(4235)+
- ID bug Cisco: CSCtq02141 - Ritardo DNS quando il DNS dell'ISP si trova sulla stessa subnet dell'IP pubblico
- ID bug Cisco: CSCuf07885 - DNS Windows: limita per scheda di rete, non per server di destinazione - 4.2+
- ID bug Cisco: CSCtf20226 - DNS del tunnel separato di macOS diverso da Windows
- ID bug Cisco: CSCtz86314 - query DNS divise da macOS non inviate tramite tunnel
- ID bug Cisco: CSCtq09624 - Comportamento DNS del tunnel diviso iOS
- ID bug Cisco: CSCts89292 - iOS ignora i domini DNS .local
- ID bug Cisco: CSCsv34395 - Supporto proxy FQDN su server DHCP
Informazioni correlate
- Esame del comportamento delle query DNS e della risoluzione dei nomi di dominio (Cisco.com) — ID documento 116016
- Guida per l'amministratore di Cisco Secure Client 5.x - Configurazione dell'accesso VPN/DSN suddiviso
- Configurazione del tunneling in split dinamico ASA/AnyConnect - ID documento 215383
- Abilita tunnel DNS per client sicuri con modulo Umbrella — ID documento 224809
- Interoperabilità tra AnyConnect e OpenDNS Roaming Client — ID documento 200395
- Supporto tecnico Cisco e download
Cronologia delle revisioni
| Revisione | Data | Commenti |
|---|---|---|
| 4.0 | 28 luglio 2026 | Aggiornamento sostanziale completo: Branding client sicuro, aggiornamento della piattaforma, tunneling split dinamico, DNS Umbrella/tunnel-all, correzioni di errori di battitura e configurazione, collegamenti correlati corretti |
| 3.0 | 23 maggio 2024 | Certificazione (Cisco.com) |
| 1.0 | 12 giugno 2014 | Release iniziale |
Il documento si applica a
- Cisco Secure Client (incluso AnyConnect) - Windows, macOS, Linux, iOS
- Criteri di gruppo VPN ad accesso remoto Cisco Secure Firewall ASA e FTD
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
4.0 |
10-Aug-2026
|
Sono state aggiornate le informazioni introduttive, ortografiche, grammaticali, URL fissi, righe orizzontali inserite per separare le sezioni per migliorarne la leggibilità e errori CCW risolti. |
3.0 |
23-May-2024
|
Certificazione |
1.0 |
12-Jun-2014
|
Versione iniziale |
Feedback