Comment fonctionne le DNS avec le point de terminaison AWS Client VPN ?

Résolution

Remarque : si des erreur se produisent lors de l'exécution des commandes de l'interface de la ligne de commande AWS (AWS CLI), rassurez-vous que vous utilisez la version la plus récente de l'AWS CLI.

Lorsque vous créez un nouveau point de terminaison d'un VPN client, spécifiez une adresse IP de serveur DNS. Utilisez la console de gestion AWS, la commande create-client-vpn-endpoint de l'AWS CLI ou l'API CreateClientVpnEndpoint pour spécifier les adresses IP dans le paramètre « Adresse IP du serveur DNS. » Vous pouvez également modifier un point de terminaison d'un VPN client existant. Utilisez la console de gestion AWS, la commande modify-client-vpn-endpoint de l'AWS CLI ou l'API ModifyClientVpnEndpoint pour modifier l'« Adresse IP du serveur DNS. »

Configurer le paramètre « Adresse IP du serveur DNS »

Pour une haute disponibilité, il est recommandé de spécifier deux serveurs DNS. Lorsque le serveur DNS principal devient inaccessible, la machine de l'utilisateur final renvoie la requête au serveur DNS secondaire.

Remarque : lorsque le serveur DNS principal répond par SERVFAIL, la demande DNS n'est pas renvoyée au serveur DNS secondaire.

Vérifiez que les utilisateurs finaux peuvent accéder aux deux serveurs DNS spécifiés une fois connectés au point de terminaison d'un VPN client. Lorsque les serveurs DNS sont inaccessibles, il y a risque d’échec des requêtes DNS et de problèmes de connexion.

Le paramètre « Adresse IP du serveur DNS » est facultatif. Lorsqu’aucun serveur DNS n'est spécifié, l'adresse IP DNS configurée sur l'appareil de l'utilisateur final est utilisée pour résoudre les requêtes DNS.

Si le serveur DNS de votre VPN client est le point de terminaison entrant AmazonProvidedDNS ou Amazon Route 53 Resolver, procédez comme suit :

• Vous pouvez résoudre les enregistrements de ressources de la zone d’hébergement privée Route 53 associée à l’aide du cloud privé virtuel (VPC).
• Lorsque le « DNS privé » est activé, les noms d'hôtes publics Amazon RDS accessibles depuis l'interface VPN se résolvent via une adresse IP privée. Il en va de même pour les noms des points de terminaison des services AWS accessibles à partir du point de terminaison de l'interface VPC.
  Remarque : assurez-vous que « Résolution DNS » et « Noms d'hôte DNS » sont activés pour le VPC associé.

Le point de terminaison d'un VPN client utilise la source NAT pour se connecter aux ressources des VPC associés.

Une fois que l'appareil client a établi le tunnel VPN client, le paramètre « Adresse IP du serveur DNS » est appliqué au tunnel complet ou au tunnel partagé :

• Tunnel complet : une fois que l'appareil client a établi le tunnel, une route pour tout le trafic passant par le tunnel VPN est ajouté à la table de routage de l'appareil de l'utilisateur final. Ensuite, tout le trafic, ainsi que le trafic DNS, est acheminé à travers le tunnel VPN client. Si le VPC associé n'a pas de route pour atteindre les serveurs DNS, il y a échec de la requête.
• Tunnel partagé : lorsque le tunnel VPN client est créé, les routes de la table de routage du VPN client sont ajoutées à la table de routage de l'appareil de l'utilisateur final. Si vous pouvez accéder au serveur DNS à travers le VPC associé, ajoutez la route des adresses IP du serveur DNS dans la table de routage du VPN client.

Les exemples suivants présentent le DNS dans des scénarios courants. Ils s'appliquent aux environnements Windows et Linux. Dans un environnement Linux, les exemples fonctionnent comme décrit uniquement lorsque la machine hôte de l'utilisateur final utilise le paramètre de mise en réseau générique.

Scénario 1 : tunnel complet avec le paramètre « Adresse IP du serveur DNS » désactivé

Exemple 1 de configuration :

• Le CIDR IPv4 du client de l'utilisateur final = 192.168.0.0/16.
• Le CIDR du VPC du point de terminaison d'un VPN client = 10.123.0.0/16.
• Adresse IP du serveur DNS local = 192.168.1.1.
• Le paramètre « Adresse IP du serveur DNS » est désactivé. Aucune adresse IP de serveur DNS n'est spécifiée.

Le paramètre « Adresse IP du serveur DNS » étant désactivé, la machine hôte de l'utilisateur final utilise le serveur DNS local pour résoudre les requêtes DNS.

Ce VPN client est configuré en mode tunnel complet. Pour envoyer tout le trafic à travers le VPN (destination 0/1 sur utun1), une route vers l'adaptateur virtuel est ajoutée. Cependant, le trafic DNS ne passe toujours pas par le VPN, en raison de la non-configuration du paramètre « Adresse IP du serveur DNS ». Le trafic DNS entre le client et le serveur DNS demeure local. La machine cliente utilise déjà une route statique privilégiée vers l'adresse du serveur DNS local (dest. 192.168.1.1/32 sur en0) pour accéder au résolveur DNS. Une fois le nom de domaine résolu dans l'adresse IP correspondante, le trafic de l'application vers l'adresse IP résolue passe par le tunnel VPN.

**Exemple d'extrait ** :

$ 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)
(...)

Exemple 2 de configuration :

• Le CIDR IPv4 du client de l'utilisateur final = 192.168.0.0/16.
• Le CIDR du VPC du point de terminaison d'un VPN client = 10.123.0.0/16.
• L'adresse IP du serveur DNS local est définie sur IP publique = 8.8.8.8.
• Le paramètre « Adresse IP du serveur DNS » est désactivé. Aucune adresse IP de serveur DNS n'est spécifiée.

Dans cet exemple, le client utilise l'adresse DNS publique 8.8.8.8 en lieu et place du serveur DNS local 198.168.1.1. Étant donné qu'il n'y a pas de route statique pour 8.8.8.8 sur en0, ce trafic transite par le tunnel VPN client. Lorsque le point de terminaison d'un VPN client n'est pas configuré pour accéder à Internet, le DNS public de la version 8.8.8.8 est inaccessible. D’où l’expiration du délai des requêtes de demande.

$ 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

Scénario 2 : tunnel partagé avec le paramètre « Adresse IP du serveur DNS » activé

Exemple de configuration :

• Le CIDR IPv4 du client de l'utilisateur final = 192.168.0.0/16.
• Le CIDR VPC du point de terminaison d'un VPN client = 10.123.0.0/16.
• Le paramètre « Adresse IP du serveur DNS » est activé et défini sur 10.10.1.228 et 10.10.0.43. Ces adresses IP représentent les adresses IP des points de terminaison entrants du résolveur Route 53 disponible dans un autre VPC (10.10.0.0/16). Les adresses IP se connectent aux points de terminaison d'un VPN client associés à un VPC à une passerelle de transit.
• Les « noms d'hôte DNS » et le « support DNS » sont activés sur le VPC associé, et une zone d’hébergement privée Route 53 associée (exemple.local) est disponible.

Ce client VPN est configuré en mode tunnel partagé. Les routes de la table de routage du VPN client sont ajoutées à la table de routage de la machine hôte de l'utilisateur final :

$ 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
(...)

Dans cet exemple, le paramètre « Adresse IP du serveur DNS » est activé.**10.10.1.228 ** et ** 10.10.0.43 ** sont configurés en tant que serveurs DNS. Lorsque le client établit le tunnel VPN, les paramètres du serveur DNS sont transmis à la machine hôte de l'utilisateur final.

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

La machine cliente émet une requête DNS qui passe par le tunnel VPN vers le VPC VPN client. La demande DNS est ensuite transmise au point de terminaison du résolveur Route 53 via une passerelle de transit. Une fois le domaine résolu dans l’adresse IP, le trafic de l'application passe également par le tunnel VPN établi. Cette opération se produit lorsque l'adresse IP de destination résolue correspond à une route de la table de routage du point de terminaison d'un VPN client.

Grâce à cette configuration, les utilisateurs finaux peuvent résoudre des noms de domaine externes utilisant une résolution DNS standard. Cette configuration résout également les enregistrements provenant de zones d’hébergement privées associées au VPC du résolveur Route 53. Elle résout aussi les noms DNS des points de terminaison d'interface et les noms d'hôtes DNS publics EC2.

$ 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)
(...)