Interoperabilität zwischen AnyConnect und dem OpenDNS Roaming-Client

Einleitung

In diesem Dokument werden einige der aktuellen Einschränkungen und die verfügbaren Problemumgehungen beschrieben, damit AnyConnect und der OpenDNS Roaming Client zusammenarbeiten können. Kunden von Cisco verlassen sich für die sichere und verschlüsselte Kommunikation mit ihren Unternehmensnetzwerken auf den AnyConnect VPN-Client. Ebenso bietet der OpenDNS Roaming-Client Benutzern die Möglichkeit, DNS-Dienste mithilfe öffentlicher OpenDNS-Server sicher zu nutzen. Beide Clients verfügen über umfassende Sicherheitsfunktionen am Endgerät. Daher ist es wichtig, dass sie miteinander interagieren.

Voraussetzungen

Kenntnisse des AnyConnect- und OpenDNS-Roaming-Clients

Vertrautheit mit ASA- oder IOS/IOS-XE-Headend-Konfiguration (Tunnel-Group/Group-Policy) für AnyConnect VPN

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• ASA- oder IOS/IOS-XE-Headend
• Endpunkt, auf dem der AnyConnect VPN-Client und der OpenDNS Roaming-Client ausgeführt werden

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• ASA-Headend mit Version 9.4
• Windows 7
• AnyConnect-Client 4.2.00096
• OpenDNS Roaming-Client 2.0.154

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.

Hintergrundinformationen

OpenDNS entwickelt zusammen mit dem Cisco AnyConnect-Team ein AnyConnect-Plug-in, das in Zukunft verfügbar sein wird. Es wurden zwar keine Termine festgelegt, durch diese Integration kann der Roaming-Client jedoch mit dem AnyConnect-Client zusammenarbeiten, ohne dass die erforderlichen Abhilfemaßnahmen ergriffen werden müssen. Dadurch kann AnyConnect auch als Bereitstellungsmechanismus für den Roaming-Client fungieren. 

Funktionalität

AnyConnect DNS-Verarbeitung

Das VPN-Headend kann für die Verarbeitung des Datenverkehrs vom AnyConnect-Client auf verschiedene Weise konfiguriert werden.

1. Vollständige Tunnelkonfiguration (Tunnel-all): Diese erzwingt die verschlüsselte Übertragung des gesamten Datenverkehrs vom Endpunkt über den VPN-Tunnel, sodass der Datenverkehr den Adapter für die öffentliche Schnittstelle niemals im Klartext verlässt.
2. Split-Tunnel-Konfiguration:

a. Split-include-Tunneling: Datenverkehr, der nur für bestimmte Subnetze oder Hosts bestimmt ist, die am VPN-Headend definiert sind, wird über den Tunnel gesendet, der gesamte andere Datenverkehr wird in unverschlüsseltem Text außerhalb des Tunnels gesendet.

b. Split-exclude tunneling: Datenverkehr, der nur für bestimmte Subnetze oder Hosts bestimmt ist, die auf dem VPN-Headend definiert sind, wird von der Verschlüsselung ausgeschlossen und verlässt die öffentliche Schnittstelle im Klartext; der gesamte andere Datenverkehr wird verschlüsselt und nur über den Tunnel gesendet.

Jede dieser Konfigurationen bestimmt, wie die DNS-Auflösung vom AnyConnect-Client behandelt wird, je nach Betriebssystem auf dem Endpunkt. In Version 4.2 wurde nach der Fehlerbehebung für CSCuf0785 eine Verhaltensänderung im DNS-Verarbeitungsmechanismus auf AnyConnect für Windows vorgenommen.

Windows 7 oder höher

Konfiguration "Tunnel-all" (und Split-Tunneling mit aktiviertem "tunnel-all DNS")

Vor AnyConnect 4.2:

Es sind nur DNS-Anfragen an DNS-Server zulässig, die unter der Gruppenrichtlinie (Tunnel-DNS-Server) konfiguriert wurden. Der AnyConnect-Treiber antwortet auf alle anderen Anfragen mit der Antwort "Kein solcher Name". Daher kann die DNS-Auflösung nur mithilfe der Tunnel-DNS-Server vorgenommen werden.

AnyConnect 4.2 und

DNS-Anfragen an beliebige DNS-Server sind zulässig, sofern sie vom VPN-Adapter stammen und über den Tunnel gesendet werden. Alle anderen Anfragen werden mit der Antwort "Kein solcher Name" beantwortet, und die DNS-Auflösung kann nur über den VPN-Tunnel durchgeführt werden.

Vor CSCuf07885 Fix beschränkt AC die Ziel-DNS-Server, mit dem Fix für CSCuf07885 wird jedoch eingeschränkt, welche Netzwerkadapter DNS-Anfragen initiieren können.

Split-include-Konfiguration (tunnel-all DNS deaktiviert und kein split-DNS)

Der AnyConnect-Treiber beeinträchtigt den nativen DNS-Resolver nicht. Aus diesem Grund wird die DNS-Auflösung in der Reihenfolge der Netzwerkadapter vorgenommen, und AnyConnect ist bei VPN-Verbindungen immer der bevorzugte Adapter. Eine DNS-Abfrage wird also zuerst über den Tunnel gesendet. Wenn sie nicht aufgelöst wird, versucht der Resolver, sie über die öffentliche Schnittstelle aufzulösen. Die split-include-Zugriffsliste muss das Subnetz für den/die Tunnel-DNS-Server enthalten. Ab AnyConnect 4.2 werden vom AnyConnect-Client automatisch Host-Routen für den/die Tunnel-DNS-Server als Split-Include-Netzwerke (sichere Routen) hinzugefügt, sodass die Split-Include-Zugriffsliste nicht mehr explizit um das Tunnel-DNS-Server-Subnetz erweitert werden muss.

Split-exclude-Konfiguration (tunnel-all DNS disabled und no split-DNS)

Der AnyConnect-Treiber beeinträchtigt den nativen DNS-Resolver nicht. Aus diesem Grund wird die DNS-Auflösung in der Reihenfolge der Netzwerkadapter vorgenommen, und AnyConnect ist bei VPN-Verbindungen immer der bevorzugte Adapter. Eine DNS-Abfrage wird also zuerst über den Tunnel gesendet. Wenn sie nicht aufgelöst wird, versucht der Resolver, sie über die öffentliche Schnittstelle aufzulösen. Die Split-Exclude-Zugriffsliste sollte nicht das Subnetz enthalten, das die Tunnel-DNS-Server abdeckt. Ab AnyConnect 4.2 werden vom AnyConnect-Client automatisch Host-Routen für den/die Tunnel-DNS-Server als Split-Include-Netzwerke (sichere Routen) hinzugefügt, wodurch eine Fehlkonfiguration in der Split-Exclude-Zugriffsliste verhindert wird.

Split-DNS (Tunnel-all DNS disabled, split-include configured)

Vor AnyConnect 4.2

DNS-Anfragen, die mit den Split-DNS-Domänen übereinstimmen, dürfen DNS-Server tunneln, jedoch nicht an andere DNS-Server weiterleiten. Um zu verhindern, dass solche internen DNS-Abfragen den Tunnel verlassen, antwortet der AnyConnect-Treiber mit "no such name" (Kein solcher Name), wenn die Abfrage an andere DNS-Server gesendet wird. Daher können Split-DNS-Domänen nur über die Tunnel-DNS-Server aufgelöst werden.

DNS-Anfragen, die nicht mit den Split-DNS-Domänen übereinstimmen, sind für andere DNS-Server zulässig, jedoch nicht für das Tunneling von DNS-Servern. Selbst in diesem Fall antwortet der AnyConnect-Treiber mit "no such name" (Kein solcher Name), wenn über den Tunnel eine Abfrage nach Nicht-Split-DNS-Domänen versucht wird. Nicht-Split-DNS-Domänen können daher nur über öffentliche DNS-Server außerhalb des Tunnels aufgelöst werden.

AnyConnect 4.2 und

DNS-Anfragen, die mit den Split-DNS-Domänen übereinstimmen, sind für alle DNS-Server zulässig, sofern sie vom VPN-Adapter stammen. Wenn die Abfrage von der öffentlichen Schnittstelle generiert wird, antwortet der AnyConnect-Treiber mit einem "no such name" (Kein solcher Name), um den Resolver zu zwingen, den Tunnel immer für die Namensauflösung zu verwenden. Daher können Split-DNS-Domänen nur über den Tunnel aufgelöst werden.

DNS-Anfragen, die nicht mit den Split-DNS-Domänen übereinstimmen, sind auf allen DNS-Servern zulässig, sofern sie vom physischen Adapter stammen. Wenn die Abfrage vom VPN-Adapter generiert wird, antwortet AnyConnect mit "no such name" (Kein solcher Name), um den Resolver zu zwingen, immer eine Namensauflösung über die öffentliche Schnittstelle zu versuchen. Nicht-Split-DNS-Domänen können daher nur über die öffentliche Schnittstelle aufgelöst werden.

Mac OS X

Konfiguration "Tunnel-all" (und Split-Tunneling mit aktiviertem "tunnel-all DNS")

Wenn AnyConnect verbunden ist, werden nur Tunnel-DNS-Server in der DNS-Konfiguration des Systems verwaltet, und DNS-Anfragen können daher nur an die Tunnel-DNS-Server gesendet werden.

Split-include-Konfiguration (tunnel-all DNS deaktiviert und kein split-DNS)

AnyConnect beeinträchtigt den nativen DNS-Resolver nicht. Die Tunnel-DNS-Server werden als bevorzugte Resolver konfiguriert, die Vorrang vor öffentlichen DNS-Servern haben, sodass sichergestellt ist, dass die erste DNS-Anforderung für eine Namensauflösung über den Tunnel gesendet wird. Da die DNS-Einstellungen unter Mac OS X global sind, ist es für DNS-Abfragen nicht möglich, öffentliche DNS-Server außerhalb des Tunnels zu verwenden, wie in CSCtf2026 dokumentiert. Ab AnyConnect 4.2 werden vom AnyConnect-Client automatisch Host-Routen für den/die Tunnel-DNS-Server als Split-Include-Netzwerke (sichere Routen) hinzugefügt, sodass die Split-Include-Zugriffsliste nicht mehr explizit um das Tunnel-DNS-Server-Subnetz erweitert werden muss.

Split-exclude-Konfiguration (tunnel-all DNS disabled und no split-DNS)

AnyConnect beeinträchtigt den nativen DNS-Resolver nicht. Die Tunnel-DNS-Server werden als bevorzugte Resolver konfiguriert, die Vorrang vor öffentlichen DNS-Servern haben, sodass sichergestellt ist, dass die erste DNS-Anforderung für eine Namensauflösung über den Tunnel gesendet wird. Da die DNS-Einstellungen unter Mac OS X global sind, ist es für DNS-Abfragen nicht möglich, öffentliche DNS-Server außerhalb des Tunnels zu verwenden, wie in CSCtf2026 dokumentiert. Ab AnyConnect 4.2 werden vom AnyConnect-Client automatisch Host-Routen für den/die Tunnel-DNS-Server als Split-Include-Netzwerke (sichere Routen) hinzugefügt, sodass die Split-Include-Zugriffsliste nicht mehr explizit um das Tunnel-DNS-Server-Subnetz erweitert werden muss.

Split-DNS (Tunnel-all DNS disabled, split-include configured)

Wenn Split-DNS für beide IP-Protokolle (IPv4 und IPv6) aktiviert ist oder nur für ein Protokoll aktiviert ist und für das andere Protokoll kein Adresspool konfiguriert ist:
True-Split-DNS wird ähnlich wie Windows erzwungen. True-Split-DNS bedeutet, dass Anforderungen, die mit den Split-DNS-Domänen übereinstimmen, nur über den Tunnel aufgelöst werden. Sie werden nicht an DNS-Server außerhalb des Tunnels weitergeleitet.

Wenn Split-DNS nur für ein Protokoll aktiviert ist und eine Client-Adresse für das andere Protokoll zugewiesen ist, wird nur "DNS-Fallback für Split-Tunneling" erzwungen. Dies bedeutet, dass AC nur DNS-Anfragen zulässt, die mit den Split-DNS-Domänen über Tunnel übereinstimmen (andere Anfragen werden von AC mit "abgelehnter" Antwort beantwortet, um Failover auf öffentliche DNS-Server zu erzwingen), jedoch nicht erzwingen kann, dass Anfragen, die mit Split-DNS-Domänen übereinstimmen, nicht unverschlüsselt über den öffentlichen Adapter gesendet werden.

Linux 

Konfiguration "Tunnel-all" (und Split-Tunneling mit aktiviertem "tunnel-all DNS")

Wenn AnyConnect verbunden ist, werden nur Tunnel-DNS-Server in der DNS-Konfiguration des Systems verwaltet, und DNS-Anfragen können daher nur an die Tunnel-DNS-Server gesendet werden.

Split-include-Konfiguration (tunnel-all DNS deaktiviert und kein split-DNS)

AnyConnect beeinträchtigt den nativen DNS-Resolver nicht. Die Tunnel-DNS-Server werden als bevorzugte Resolver konfiguriert, die Vorrang vor öffentlichen DNS-Servern haben, sodass sichergestellt ist, dass die erste DNS-Anforderung für eine Namensauflösung über den Tunnel gesendet wird.

Split-exclude-Konfiguration (tunnel-all DNS disabled und no split-DNS)

AnyConnect beeinträchtigt den nativen DNS-Resolver nicht. Die Tunnel-DNS-Server werden als bevorzugte Resolver konfiguriert, die Vorrang vor öffentlichen DNS-Servern haben, sodass sichergestellt ist, dass die erste DNS-Anforderung für eine Namensauflösung über den Tunnel gesendet wird.

Split-DNS (Tunnel-all DNS disabled, split-include configured)

Wenn Split-DNS aktiviert ist, wird nur "DNS-Fallback für Split-Tunneling" erzwungen. Dies bedeutet, dass AC nur DNS-Anfragen zulässt, die mit den Split-DNS-Domänen über Tunnel übereinstimmen (andere Anfragen werden von AC mit "abgelehnter" Antwort beantwortet, um Failover auf öffentliche DNS-Server zu erzwingen), jedoch nicht erzwingen kann, dass Anfragen, die mit Split-DNS-Domänen übereinstimmen, nicht unverschlüsselt über den öffentlichen Adapter gesendet werden.

OpenDNS-Roaming-Client

Der Roaming-Client ist eine Software, die DNS-Dienste auf dem Endpunkt verwaltet und die öffentlichen OpenDNS-Server verwendet, um den DNS-Verkehr zu sichern und zu verschlüsseln.

Idealerweise sollte der Client in einem geschützten und verschlüsselten Zustand sein. Wenn der Client jedoch keine TLS-Sitzung mit dem öffentlichen OpenDNS-Resolver-Server (208.67.222.222) herstellen kann, versucht er, den DNS-Datenverkehr unverschlüsselt auf UDP-Port 53 an 208.67.222.222 zu senden. Der Roaming-Client verwendet ausschließlich die IP-Adresse des öffentlichen Auflösers von OpenDNS 208.67.222.222 (es gibt einige andere, z. B. 208.67.220.220, 208.67.222.220 und 208.67.22). 220 222). Der Roaming-Client legt nach der Installation 127.0.0.1 (localhost) als lokalen DNS-Server fest und überschreibt die aktuellen DNS-Einstellungen pro Schnittstelle. Aktuelle DNS-Einstellungen werden in lokalen resolv.conf-Dateien (auch unter Windows) im Konfigurationsordner des Roaming-Clients gespeichert. OpenDNS sichert auch die DNS-Server, die über den AnyConnect-Adapter bezogen werden. Wenn beispielsweise 192.168.92.2 der DNS-Server auf dem öffentlichen Adapter ist, erstellt OpenDNS die Datei resolv.conf am folgenden Speicherort:

C:\ProgramData\OpenDNS\ERC\Resolver1-LocalAreaConnection-resolv.conf
Namenserver 192.168.92.2

Der Roaming-Client verschlüsselt jedes Paket, das auf OpenDNS festgelegt ist. Er startet jedoch keinen Verschlüsselungstunnel zu 208.67.222.222. Der Roaming-Client verfügt über eine optionale IP-Layer-Erzwingungsfunktion, die eine IPSec-Verbindung für Nicht-DNS-Zwecke öffnet, um IP-Adressen zu blockieren. Bei aktiver AnyConnect-Verbindung wird diese Option automatisch deaktiviert. Sie wird auch an 127.0.0.1:53 gebunden, um lokal auf dem Computer generierte Abfragen zu empfangen. Wenn der Endpunkt einen Namen auflösen muss, werden die lokalen Abfragen aufgrund der Überschreibung an 127.0.0.1 weitergeleitet, und dann werden sie vom zugrunde liegenden dnscrypt-proxy-Prozess des Roaming-Clients über den verschlüsselten Kanal an die öffentlichen OpenDNS-Server weitergeleitet.

Wenn der DNS-Fluss nicht zu 127.0.0.1:53 zugelassen ist, kann der Roaming-Client nicht ausgeführt werden. Es geschieht Folgendes: Wenn der Client die öffentlichen DNS-Server oder die gebundene Adresse 127.0.0.1:53 nicht erreichen kann, wechselt er in den Fail-Open-Status und stellt die DNS-Einstellungen auf den lokalen Adaptern wieder her. Im Hintergrund sendet es weiterhin Diagnosetools an 208.67.222.222 und kann in den aktiven Modus wechseln, wenn die sichere Verbindung wiederhergestellt wird.

Einschränkungen

Wenn man sich die High-Level-Funktionalität beider Clients anschaut, wird klar, dass der Roaming-Client die Möglichkeit haben muss, die lokalen DNS-Einstellungen zu ändern und sich an 127.0.0.1:53 zu binden, um Abfragen über den sicheren Kanal weiterzuleiten. Wenn eine VPN-Verbindung besteht, sind die einzigen Konfigurationen, bei denen AnyConnect den nativen DNS-Resolver nicht beeinträchtigt, die Split-Include- und Split-Exclude-Funktion (bei deaktiviertem Split-Tunnel-All-DNS). Daher wird derzeit empfohlen, eine dieser Konfigurationen zu verwenden, wenn der Roaming-Client ebenfalls verwendet wird. Der Roaming-Client verbleibt in einem ungeschützten/unverschlüsselten Zustand, wenn die Konfiguration tunnel-all verwendet wird oder Split-tunnel-all DNS aktiviert wird, wie im Bild gezeigt.

Problemumgehung

Wenn die Kommunikation zwischen dem Roaming-Client und den OpenDNS-Servern mithilfe des VPN-Tunnels geschützt werden soll, kann eine Dummy-Split-Exclude-Zugriffsliste auf dem VPN-Headend verwendet werden. Dies entspricht einer vollständigen Tunnelkonfiguration am nächsten. Wenn keine solche Anforderung besteht, kann split-include verwendet werden, wenn die Zugriffsliste die öffentlichen OpenDNS-Server nicht enthält, oder split-exclude, wenn die Zugriffsliste die öffentlichen OpenDNS-Server enthält.

Darüber hinaus können bei Verwendung des Roaming-Clients keine Split-DNS-Modi verwendet werden, da dies zu einem Verlust der lokalen DNS-Auflösung führt. Split-tunnel-all DNS sollte ebenfalls deaktiviert bleiben, wird jedoch teilweise unterstützt und sollte es ermöglichen, dass der Roaming-Client nach dem Failover verschlüsselt wird. 

Konfigurationen

Tunnel OpenDNS-Datenverkehr

In diesem Beispiel wird eine Dummy-IP-Adresse in der Split-Exclude-Zugriffsliste verwendet. Bei dieser Konfiguration erfolgt die gesamte Kommunikation mit 208.67.222.222 über den VPN-Tunnel, und der Roaming-Client arbeitet in einem verschlüsselten und geschützten Zustand.

ciscoasa# sh run access-li split
access-list split standard permit host 2.2.2.2

ciscoasa# sh run group-policy
group-policy GroupPolicy-OpenDNS internal
group-policy GroupPolicy-OpenDNS attributes
 wins-server none
 dns-server value 1.1.1.1
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy excludespecified
 split-tunnel-network-list value split
 default-domain value cisco.com
 address-pools value acpool
 webvpn
  anyconnect profiles value AnyConnect type user
ciscoasa#

OpenDNS-Verkehr vom VPN-Tunnel ausschließen

In diesem Beispiel wird die OpenDNS-Resolver-Adresse in der Split-Exclude-Zugriffsliste verwendet. Bei dieser Konfiguration erfolgt die gesamte Kommunikation mit 208.67.222.222 außerhalb des VPN-Tunnels, und der Roaming-Client arbeitet in einem verschlüsselten und geschützten Zustand.

ciscoasa# sh run access-li split
access-list split standard permit host 208.67.222.222

ciscoasa# sh run group-policy
group-policy GroupPolicy-OpenDNS internal
group-policy GroupPolicy-OpenDNS attributes
 wins-server none
 dns-server value 1.1.1.1
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy excludespecified
 split-tunnel-network-list value split
 default-domain value cisco.com
 address-pools value acpool
 webvpn
  anyconnect profiles value AnyConnect type user
ciscoasa#

Dieses Beispiel zeigt eine Split-Include-Konfiguration für ein internes Subnetz 192.168.1.0/24. Bei dieser Konfiguration wird der Roaming-Client weiterhin verschlüsselt und geschützt betrieben, da der Datenverkehr zu 208.67.222.222 nicht über den Tunnel gesendet wird.

ciscoasa# sh run access-li split
access-list split standard permit 192.168.1.0 255.255.255.0

ciscoasa# sh run group-policy
group-policy GroupPolicy-OpenDNS internal
group-policy GroupPolicy-OpenDNS attributes
 wins-server none
 dns-server value 1.1.1.1
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value split
 default-domain value cisco.com
 address-pools value acpool
 webvpn
  anyconnect profiles value AnyConnect type user
ciscoasa#

Note: Split-tunnel-all-dns must be disabled in all of the  scenarios

Überprüfung

Wenn eine VPN-Verbindung besteht, sollte der Roaming-Client geschützt und verschlüsselt angezeigt werden, wie in diesem Bild gezeigt: