Wie funktioniert DNS mit meinem Endpunkt im AWS Client VPN?

Behebung

**Hinweis:**Sollten beim Ausführen von Befehlen des AWS Command Line Interface (AWS CLI) Fehler auftreten, stellen Sie sicher, dass Sie die neueste AWS-CLI-Version verwenden.

Wenn Sie einen neuen Client-VPN-Endpunkt erstellen, geben Sie eine DNS-Server-IP-Adresse an. Verwenden Sie die AWS-Managementkonsole, den AWS-CLI-Befehl create-client-vpn-endpoint oder das CreateClientVpnEndpoint-API, um die IP-Adressen im Parameter „DNS-Server-IP-Adresse“ anzugeben. Oder ändern Sie einen vorhandenen Client-VPN-Endpunkt. Verwenden Sie die AWS-Managementkonsole, den AWS-CLI-Befehl modify-client-vpn-endpoint oder die ModifyClientVpnEndpoint-API, um die „IP-Adresse des DNS-Servers“ zu ändern.

Konfigurieren Sie den Parameter „DNS-Server-IP-Adresse“

Für eine hohe Verfügbarkeit empfiehlt es sich, zwei DNS-Server anzugeben. Wenn der primäre DNS-Server nicht mehr erreichbar ist, sendet das Endbenutzergerät die Anfrage erneut an den sekundären DNS-Server.

Hinweis: Wenn der primäre DNS-Server mit SERVFAIL antwortet, wird die DNS-Anfrage nicht erneut an den sekundären DNS-Server gesendet.

Stellen Sie sicher, dass Endbenutzer beide angegebenen DNS-Server erreichen können, nachdem die Endbenutzer eine Verbindung zum Client-VPN-Endpunkt hergestellt haben. Wenn die DNS-Server nicht erreichbar sind, schlagen DNS-Anfragen möglicherweise fehl und führen zu Verbindungsproblemen.

Der Parameter „DNS-Server-IP-Adresse“ ist optional. Wenn kein DNS-Server angegeben ist, wird die auf dem Gerät des Endbenutzers konfigurierte DNS-IP-Adresse zur Lösung von DNS-Abfragen verwendet.

Wenn es sich bei Ihrem Client-VPN-DNS-Server um den eingehenden Endpunkt AmazonProvidedDNS oder Amazon Route 53 Resolver handelt, folgen Sie diesen Richtlinien:

• Sie können die Ressourceneinträge der privaten gehosteten Zone Route 53 auflösen, die der Virtual Private Cloud (VPC) zugeordnet ist.
• Wenn „Private DNS“ aktiviert ist, werden öffentliche Amazon-RDS-Hostnamen, auf die über die VPN-Schnittstelle zugegriffen werden kann, zu einer privaten IP-Adresse aufgelöst. Dies gilt auch für AWS-Serviceendpunktnamen, auf die vom VPC-Schnittstellenendpunkt aus zugegriffen werden kann.
  Hinweis: Vergewissern Sie sich, dass „DNS-Auflösung“ und „DNS-Hostnamen“ für die zugehörige VPC aktiviert sind.

Der Client-VPN-Endpunkt verwendet das Quell-NAT, um eine Verbindung zu Ressourcen in den zugehörigen VPCs herzustellen.

Nachdem das Client-Gerät den Client-VPN-Tunnel eingerichtet hat, wird der Parameter „DNS-Server-IP-Adresse“ auf den Voll- oder Split-Tunnel angewendet:

• Volltunnel: Nachdem das Client-Gerät den Tunnel eingerichtet hat, wird der Routing-Tabelle des Endbenutzergeräts eine Route für den gesamten Datenverkehr durch den VPN-Tunnel hinzugefügt. Anschließend wird der gesamte Datenverkehr, einschließlich DNS-Verkehr, durch den Client-VPN-Tunnel geleitet. Wenn die zugehörige VPC keine Route hat, um die DNS-Server zu erreichen, schlägt die Suche fehl.
• **Split-Tunnel:**Bei Erstellung des Client-VPN-Tunnels werden die Routen in der Client-VPN-Routing-Tabelle zur Routing-Tabelle des Endbenutzergeräts hinzugefügt. Wenn Sie den DNS-Server über die zugehörige VPC erreichen können, fügen Sie die Route der IP-Adressen des DNS-Servers in die Client-VPN-Routing-Tabelle ein.

Die folgenden Beispiele demonstrieren DNS in gängigen Szenarien. Sie gelten sowohl für Windows- als auch für Linux-Umgebungen. In einer Linux-Umgebung funktionieren die Beispiele jedoch nur dann wie beschrieben, wenn der Host-Computer des Endbenutzers die generische Netzwerkeinstellung verwendet.

Szenario 1: Volltunnel mit deaktiviertem Parameter „DNS-Server-IP-Adresse“

**Konfiguration für Beispiel 1: **

• IPv4-CIDR des Endbenutzer-Clients = 192.168.0.0/16.
• CIDR der Client-VPN-Endpunkt-VPC = 10.123.0.0/16.
• Lokale DNS-Server-IP-Adresse = 192.168.1.1.
• Der Parameter „DNS-Server-IP-Adresse“ ist deaktiviert. Es wurden keine IP-Adressen für DNS-Server angegeben.

Da der Parameter „DNS-Server-IP-Adresse“ deaktiviert ist, verwendet der Hostcomputer des Endbenutzers den lokalen DNS-Server, um DNS-Abfragen zu lösen.

Dieses Client-VPN ist im Volltunnelmodus konfiguriert. Eine Route, die auf den virtuellen Adapter verweist, wird hinzugefügt, um den gesamten Datenverkehr über das VPN zu senden (Ziel 0/1 über utun1). DNS-Verkehr wird jedoch immer noch nicht über das VPN übertragen, da der Parameter „DNS-Server-IP-Adresse“ nicht konfiguriert ist. Der DNS-Verkehr zwischen dem Client und dem DNS-Server bleibt lokal. Der Client-Computer hat bereits eine bevorzugte statische Route zur lokalen DNS-Server-IP (dest. 192.168.1.1/32 über en0), um den DNS-Resolver zu erreichen. Nachdem der Domainname auf die entsprechende IP aufgelöst wurde, wird der Anwendungsdatenverkehr zur aufgelösten IP über den VPN-Tunnel übertragen.

Beispielausschnitt:

$ cat /etc/resolv.conf | grep nameservernameserver 192.168.1.1

$ netstat -nr -f inet | grep -E 'utun1|192.168.1.1'0/1                192.168.0.1        UGSc           16        0   utun1
192.168.1.1/32     link#4             UCS             1        0     en0
(...)

$ dig amazon.com;; ANSWER SECTION:
amazon.com.        32    IN    A    176.32.98.166
;; SERVER: 192.168.1.1#53(192.168.1.1)
(...)

Konfiguration von Beispiel 2:

• IPv4-CIDR des Endbenutzer-Clients = 192.168.0.0/16.
• CIDR der Client-VPN-Endpunkt-VPC = 10.123.0.0/16.
• Die IP-Adresse des lokalen DNS-Servers ist auf öffentliche IP = 8.8.8.8 festgelegt.
• Der Parameter „DNS-Server-IP-Adresse“ ist deaktiviert. Es wurden keine IP-Adressen für DNS-Server angegeben.

In diesem Beispiel verwendet der Client anstelle des lokalen DNS-Servers unter 198.168.1.1 die öffentliche DNS-Adresse unter 8.8.8.8. Da es keine statische Route für 8.8.8.8 über en0 gibt, wird dieser Datenverkehr über den Client-VPN-Tunnel übertragen. Wenn der Client-VPN-Endpunkt nicht für den Zugriff auf das Internet konfiguriert ist, ist das öffentliche DNS unter 8.8.8.8 nicht erreichbar. Dann kommt es bei den Anforderungsabfragen zu einem Timeout.

$ cat /etc/resolv.conf | grep nameservernameserver 8.8.8.8

$ netstat -nr -f inet | grep -E 'utun1|8.8.8.8'0/1                192.168.0.1      UGSc            5        0   utun1

$ dig amazon.com(...)
;; connection timed out; no servers could be reached

Szenario 2: Split-Tunnel mit aktiviertem Parameter „DNS-Server-IP-Adresse“

Beispielkonfiguration:

• IPv4-CIDR des Endbenutzer-Clients = 192.168.0.0/16.
• VPC-CIDR des Client-VPN-Endpunkts = 10.123.0.0/16.
• Der Parameter „DNS-Server-IP-Adresse“ ist aktiviert und auf 10.10.1.228 und 10.10.0.43 festgelegt. Diese IP-Adressen stellen die IP-Adressen der eingehenden Endpunkte des Route 53 Resolvers dar, die sich in einer anderen VPC befinden (10.10.0.0/16). Die IP-Adressen stellen eine Verbindung zu den Client-VPN-Endpunkten her, die einer VPC mit einem Transit-Gateway zugeordnet sind.
• Für die zugehörige VPC sind „DNS-Hostnamen“ und „DNS-Unterstützung“ aktiviert und sie hat eine zugehörige privat gehostete Route-53-Zone (example.local).

Dieses Client-VPN ist im Split-Tunnel-Modus konfiguriert. Die Routen in der Client-VPN-Routing-Tabelle werden der Routing-Tabelle des Hostcomputers des Endbenutzers hinzugefügt:

$ netstat -nr -f inet | grep utun1(...)
10.10/16           192.168.0.1        UGSc            2        0   utun1 # Route 53 Resolver inbound endpoints VPC CIDR
10.123/16          192.168.0.1        UGSc            0        0   utun1 # Client VPN VPC CIDR
(...)

In diesem Beispiel ist der Parameter „DNS-Server-IP-Adresse“ aktiviert. 10.10.1.228 und 10.10.0.43 sind als DNS-Server konfiguriert. Wenn der Client den VPN-Tunnel einrichtet, werden die DNS-Serverparameter an den Host-Computer des Endbenutzers übertragen.

$ cat /etc/resolv.conf | grep nameservernameserver 10.10.1.228 # Primary DNS server
nameserver 10.10.0.43 # Secondary DNS server

Eine vom Client-Computer ausgegebene DNS-Abfrage wird über den VPN-Tunnel zur Client-VPN-VPC übertragen. Als Nächstes wird die DNS-Anfrage über ein Transit-Gateway an den Route-53-Resolver-Endpunkt weitergeleitet. Nachdem die Domain in eine IP-Adresse aufgelöst wurde, wird der Anwendungsverkehr auch über den eingerichteten VPN-Tunnel geleitet. Dies ist der Fall, solange die aufgelöste Ziel-IP-Adresse mit einer Route aus der Routing-Tabelle des Client-VPN-Endpunkts übereinstimmt.

Mit dieser Konfiguration können Endbenutzer externe Domainnamen auflösen, die die Standard-DNS-Auflösung verwenden. Diese Konfiguration löst auch Datensätze aus privaten Hosting-Zonen auf, die der Route 53 Resolver VPC zugeordnet sind. Sie löst auch DNS-Namen von Schnittstellenendpunkten und öffentliche EC2-DNS-Hostnamen auf.

$ dig amazon.com;; ANSWER SECTION:
amazon.com.        8    IN    A    176.32.103.205
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)

$ dig test.example.local # Route 53 private hosted zone record ;; ANSWER SECTION:
test.example.local. 10 IN A 10.123.2.1
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)

$ dig ec2.ap-southeast-2.amazonaws.com # VPC interface endpoint to EC2 service in Route 53 Resolver VPC;; ANSWER SECTION:
ec2.ap-southeast-2.amazonaws.com. 60 IN    A    10.10.0.33
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)

$ dig ec2-13-211-254-134.ap-southeast-2.compute.amazonaws.com # EC2 instance public DNS hostname running in Route 53 Resolver VPC;; ANSWER SECTION:
ec2-13-211-254-134.ap-southeast-2.compute.amazonaws.com. 20 IN A 10.10.1.11
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)