Comment le DNS fonctionne-t-il avec mon point de terminaison AWS Client VPN ?

Dernière mise à jour : 10/04/2020

Je suis en train de créer un point de terminaison AWS Client VPN. Je dois spécifier les serveurs DNS que mes utilisateurs finaux (clients connectés à AWS Client VPN) doivent interroger aux fins de la résolution du nom de domaine. Comment le DNS fonctionne-t-il avec mon point de terminaison AWS Client VPN ?

Résolution

Vous pouvez spécifier les adresses IP des serveurs DNS lorsque vous créez un nouveau point de terminaison Client VPN. Pour ce faire, spécifiez les adresses IP dans le paramètre « Adresse IP de serveur DNS » en utilisant l'AWS Management Console, de l'interface de ligne de commande AWS (AWS CLI) ou de l'API.

Vous pouvez également modifier un point de terminaison Client VPN existant afin de spécifier les adresses IP des serveurs DNS. Pour ce faire, modifiez le paramètre « Adresse IP de serveur DNS » par le biais de l'AWS Management Console, de l'AWS CLI ou de l'API.

Éléments à prendre en compte pour configurer le paramètre « Adresse IP de serveur DNS »

  • Pour une haute disponibilité, il est recommandé de spécifier deux serveurs DNS. Si le serveur DNS principal est inaccessible, le dispositif de l'utilisateur final envoie à nouveau la requête au serveur DNS secondaire.
    Remarque : si le serveur DNS principal renvoie « SERVFAIL », la requête DNS n'est pas renvoyée au serveur DNS secondaire.
  • Confirmez que les utilisateurs finaux peuvent accéder aux deux serveurs DNS spécifiés après qu'ils se sont connectés au point de terminaison Client VPN. Les recherches DNS dépendent du paramètre « Adresse IP de serveur DNS ». Si les serveurs DNS ne sont pas accessibles, les requêtes DNS peuvent échouer et causer des problèmes de connectivité.
  • Le paramètre « Adresse IP du serveur DNS » est facultatif. Si aucun serveur DNS n'est spécifié, l'adresse IP DNS configurée sur le dispositif de l'utilisateur final est utilisée pour résoudre les requêtes DNS.
  • Lorsque vous utilisez AmazonProvidedDNS (ou le point de terminaison entrant du résolveur Route 53) en tant que serveur DNS Client VPN :
    • Vous pouvez résoudre les enregistrements de ressources de la zone hébergée privée Amazon Route 53 associée au VPC.
    • Les noms d'hôte publics d'Amazon Relational Database Service (Amazon RDS) et les noms des points de terminaison des services AWS qui sont accessibles depuis le point de terminaison de l'interface du VPC (option « DNS privé » activée) sont résolus en une adresse IP privée.
      Remarque : assurez-vous que les options « Résolution DNS » et « Noms d'hôte DNS » sont activées pour le VPC associé.
  • N'oubliez pas que le point de terminaison Client VPN utilise le NAT source afin de se connecter aux ressources des VPC associés.
  • Après que le dispositif du client a établi le tunnel Client VPN, le paramètre « Adresse IP du serveur DNS » est appliqué. Il est appliqué, que le tunnel soit complet ou fractionné.
    • Tunnel complet : après que le dispositif du client a établi le tunnel, une route pour l'ensemble du trafic dans le tunnel VPN est ajoutée à la table de routage du dispositif de l'utilisateur final. Cela entraîne le routage de l'ensemble du trafic (y compris le trafic DNS) via le tunnel Client VPN. La recherche DNS peut échouer si le VPC associé du Client VPN (sous-réseau) et la table de routage Client VPN ne disposent pas d'une route appropriée afin d'atteindre les serveurs DNS configurés.
    • Tunnel fractionné : lorsque le tunnel Client VPN est établi, seules les routes de la table de routage Client VPN sont ajoutées à la table de routage du dispositif de l'utilisateur final. Si vous pouvez atteindre le serveur DNS par le biais du VPC associé du Client VPN, assurez-vous d'ajouter une route pour les adresses IP du serveur DNS dans la table de routage Client VPN.

Remarque : les exemples suivants illustrent le fonctionnement du DNS dans certains scénarios courants. Ces exemples s'appliquent aux environnements Windows et Linux. Cependant, dans un environnement Linux, les exemples ne fonctionnent comme décrit que si la machine hôte de l'utilisateur final utilise le paramètre de réseaux génériques.

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

Exemple 1 :

  • L'IPv4 CIDR du client de l'utilisateur final = 192.168.0.0/16.
  • Le CIDR du VPC du point de terminaison Client VPN = 10.123.0.0/16.
  • L'adresse IP du serveur DNS local = 192.168.1.1.
  • Le paramètre « Adresse IP du serveur DNS » est désactivé (aucune adresse IP du serveur DNS spécifiée).
  • Étant donné que le paramètre « Adresse IP du serveur DNS » est désactivé, la machine hôte de l'utilisateur final utilise le serveur DNS local afin de résoudre les requêtes DNS.

Le Client VPN est configuré en mode de tunnel complet. Une route pointant vers l'adaptateur virtuel est ajoutée pour envoyer l'ensemble du trafic sur le VPN (destination 0/1 sur utun1). Cependant, le trafic DNS ne passe toujours pas par le VPN, car le paramètre « Adresse IP du serveur DNS » n'est pas configuré. Le trafic DNS entre le client et le serveur DNS reste local. La machine du client dispose déjà d'une route statique préférée vers l'adresse IP du serveur DNS local (dest. 192.168.1.1/32 sur en0), afin que le résolveur DNS local puisse être atteint. Lorsque le nom de domaine est résolu en l'adresse IP correspondante, le trafic de l'application vers l'adresse IP résolue passe par le tunnel VPN.

Un extrait de cet exemple se trouve ci-dessous :

$ cat /etc/resolv.conf | grep nameserver
nameserver 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 :

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

Dans ce scénario, plutôt que d'utiliser le serveur DNS local à 198.168.1.1, le client utilise un DNS public en tant qu'adresse IP de son serveur DNS local (dans cet exemple, 8.8.8.8). Étant donné qu'il n'y a pas de route statique pour 8.8.8.8 sur en0, le trafic destiné à 8.8.8.8 passe par le tunnel Client VPN. Si le point de terminaison Client VPN n'est pas configuré pour accéder à Internet, le DNS public (8.8.8.8) est injoignable et le délai des requêtes est expiré.

$ cat /etc/resolv.conf | grep nameserver
nameserver 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 n° 2 : tunnel fractionné avec le paramètre « Adresse IP du serveur DNS » activé

Dans cet exemple :

  • L'IPv4 CIDR du client de l'utilisateur final = 192.168.0.0/16.
  • Le CIDR du VPC du point de terminaison Client VPN = 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, qui sont présents dans un autre VPC (10.10.0.0/16) connecté avec une passerelle de transit vers le VPC associé du point de terminaison Client VPN.
  • Les paramètres « Noms d'hôte DNS » et « Support DNS » du VPC associé sont activés. Le VPC associé dispose d'une zone hébergée privée Route 53 associée (example.local).

Le Client VPN est configuré en mode de tunnel fractionné. Les routes dans la table de routage Client VPN 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
(...)

Étant donné que le paramètre « Adresse IP du serveur DNS » est activé, et que  10.10.1.228 et 10.10.0.43 sont configurés en tant que serveurs DNS, ces paramètres de serveur DNS sont transmis vers la machine hôte de l'utilisateur final lorsque le client établit le tunnel VPN :

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

Une requête DNS émise par la machine du client passe par le tunnel VPN en direction du VPC Client VPN . Ensuite, le processus NAT source est appliqué à la requête DNS et celle-ci est transmise au point de terminaison du résolveur Amazon Route 53 par le biais d'une passerelle de transit. Lorsque le domaine est résolu en une adresse IP, le trafic de l'application passe également par le tunnel VPN établi (tant que l'adresse IP de destination résolue correspond à une route de la table de routage du point de terminaison Client VPN).

Grâce à cette configuration, les utilisateurs finaux peuvent résoudre :

  • Noms de domaine externes par le biais de la résolution DNS standard.
  • Enregistrements des zones hébergées privées associées au VPC du résolveur Route 53.
  • Noms DNS des points de terminaison d'interface et 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)
(...)

Cet article vous a-t-il été utile ?

Que pouvons-nous améliorer ?


Besoin de plus d'aide ?