DNS avec AWS Client VPN : utilisez le résolveur du VPC, pas le sous-réseau

Le point de terminaison se trouve dans 10.0.8.0/24, donc le résolveur doit être 10.0.8.2. C’est le raisonnement que j’entends le plus souvent, et il est faux deux fois. Route 53 Resolver répond sur la plage IPv4 principale du VPC plus deux, qui pour un VPC de 10.0.0.0/16 est 10.0.0.2, quel que soit le sous-réseau utilisé par le point de terminaison. La seconde erreur est plus discrète : mettre la bonne adresse dans le point de terminaison ne signifie pas que le système d’exploitation du client la consulte un jour. Les deux erreurs produisent le même symptôme : la résolution de noms fonctionne pour certains clients et échoue pour d’autres.

Le mythe commence par l’association du sous-réseau

L’association concerne l’emplacement des interfaces réseau élastiques des connexions clientes, pas l’adresse de résolveur qui existe. Les sous-réseaux du point de terminaison donnent aux clients une adresse à l’intérieur du VPC, et aucun ne porte son propre résolveur.

Une fois ces deux idées séparées, l’arithmétique cesse d’être mystérieuse et le dépannage passe au client, où la plupart de ces cas se terminent réellement.

Calculez l’adresse à partir de la plage principale du VPC

Prenez le CIDR IPv4 principal du VPC et ajoutez deux à l’adresse réseau. 10.0.0.0/16 donne 10.0.0.2, 172.31.0.0/16 donne 172.31.0.2, et un VPC doté d’une plage secondaire garde le résolveur sur la principale. Un sous-réseau 10.0.8.0/24 dans ce VPC ne le déplace pas. Notez l’adresse à côté de l’ID du VPC avant de toucher au point de terminaison, car le nombre est une propriété du VPC et non de la connexion.

Le VPC répond aussi sur l’adresse link-local 169.254.169.253. Cette adresse est joignable depuis l’intérieur du VPC, mais ce n’est pas une destination routée d’usage général pour un portable à l’autre bout d’un tunnel.

Il existe donc deux adresses de résolveur valides, et aucune n’est le sous-réseau plus deux.

Ce que fait le réglage du point de terminaison et ce qu’il ne fait pas

Le point de terminaison Client VPN possède des champs de serveur DNS, et là où la console propose une option de résolveur VPC, elle remplit la même idée. Les définir change ce que le service remet aux clients lors de l’établissement de la connexion. Cela ne change pas ce qu’un client OpenVPN non géré fait de cette valeur, car le client doit encore l’appliquer au système d’exploitation. C’est de cet écart que vient « ça marche sur mon Mac mais pas sur la machine Linux ».

Sous Linux, l’intégration du résolveur appartient au gestionnaire de connexions et non à l’utilisateur. Modifier /etc/resolv.conf à la main prouve que l’adresse fonctionne pour une session, puis disparaît à la reconnexion : voilà pourquoi tant de cas réparés reviennent le lendemain matin.

Vérifiez le résolveur actif sur le client après connexion, pas la page de configuration du point de terminaison.

Le tunneling divisé peut déjouer un résolveur correct

Avec le tunneling divisé, seules les routes poussées dans le tunnel sont utilisées. Si l’adresse du résolveur n’est couverte par aucune route, la requête sort par l’interface locale et c’est votre routeur domestique qui répond. L’adresse du point de terminaison reste correcte et la résolution échoue toujours. Ajoutez la route du résolveur, puis testez à nouveau.

Des plages locales qui se chevauchent donnent le même résultat de façon plus désagréable : la requête reçoit une réponse, mais du mauvais serveur.

N’ouvrez pas de groupes de sécurité pour l’adresse Amazon DNS

L’instinct, quand les résolutions expirent, est d’ajouter une règle autorisant UDP 53 vers l’adresse du résolveur. AWS documente que les groupes de sécurité et les ACL réseau ne filtrent pas le trafic Amazon DNS comme ils filtrent le trafic vers une instance DNS personnalisée. Ouvrir ces règles ne change rien pour le résolveur du VPC et élargit la frontière sans raison. Un résolveur que vous exploitez vous-même est un autre cas et a bien besoin de ses propres règles.

Si les deux figurent dans votre conception, vérifiez vers lequel le client pointe réellement avant de modifier la moindre règle.

Vérifiez le chemin, puis mesurez autre chose

Résolvez un nom public, résolvez un nom privé enregistré dans une zone hébergée privée associée au VPC, et lisez entre les deux le résolveur actif du client. Cette séquence sépare « l’adresse du résolveur est fausse » de « la zone n’est pas associée » et de « le client a ignoré le réglage ». Chacun a un correctif différent, et aucun n’est un problème de débit.

Une résolution réussie ne dit rien sur le débit soutenu, alors gardez ces deux conversations séparées dans votre compte rendu.