Le DNS privé fonctionne dans le VPC mais pas via le VPN
Un nom privé qui se résout dans EC2 mais pas via le VPN est un problème de chemin de résolution. Lisez la forme de la panne avant de modifier l'enregistrement de zone.
Un nom privé se résout depuis une instance EC2 mais pas depuis un portable connecté par le VPN, et la zone paraît correcte dans la console. Le réflexe est de modifier l'enregistrement, ce qui n'est presque jamais le problème. L'enregistrement répond à quelqu'un ; il ne répond simplement pas à votre portable. Ce qui diffère entre les deux appelants, c'est le résolveur qu'ils interrogent et la présence d'un chemin pris en charge vers la vue DNS du VPC.
Je commence par prouver que l'enregistrement existe, puis je passe le reste du temps sur le chemin de la requête. Ce sont des systèmes distincts et ils échouent de manières différentes.
Lisez la forme de la panne avant de changer quoi que ce soit
Trois issues signifient trois choses différentes, et une seule requête les distingue : lancez dig pour le nom contre le résolveur que le client utilise réellement.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
Un délai d'attente est une affirmation sur le réseau. NXDOMAIN est une affirmation sur la vue DNS. Une réponse publique est une affirmation sur la politique. Modifier un enregistrement de zone alors qu'un délai d'attente existe jette la seule preuve utile de l'affaire.
Pourquoi l'adresse plus deux du VPC n'est pas un résolveur distant
L'adresse CIDR plus deux est un service local pour les ressources à l'intérieur du VPC. AWS documente que le transfert de requêtes depuis des réseaux locaux, ou depuis les serveurs DNS d'un autre VPC, directement vers cette adresse n'est pas pris en charge et peut produire des résultats instables.
Cela ne veut pas dire qu'une expérience ne semble jamais fonctionner. Cela veut dire que le comportement n'est pas un contrat que vous pouvez mettre dans un script d'assistance. La direction prise en charge est un point de terminaison Resolver entrant : une paire d'adresses dans votre VPC, joignable depuis le réseau que vous contrôlez, qui accepte les requêtes venant de l'extérieur d'AWS.
Construisez le chemin dans l'ordre où il échoue proprement
Trois sauts doivent exister, et chacun a sa propre manière d'échouer.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesLe redirecteur a besoin d'une route vers les adresses du point de terminaison à travers le VPN, et le chemin de retour doit fonctionner aussi. Pour le DNS classique sur le port 53, le point de terminaison répond en UDP et en TCP, donc les deux protocoles doivent être autorisés et tous deux doivent survivre à une inspection avec état au milieu.
Vérifiez ensuite la vue DNS séparément. Une zone hébergée privée n'est visible que pour les VPC auxquels elle est associée, ou via un accord de partage délibéré. Un point de terminaison joignable ne rend pas à lui seul toutes les zones privées résolubles dans son contexte de résolution.
Un point de terminaison sortant sert la direction opposée et ne répondra pas à une requête venant de votre portable.
Vérifiez aux deux extrémités
Interrogez depuis le client vers le redirecteur, puis depuis le redirecteur vers le point de terminaison. Si le client échoue alors que le redirecteur réussit, l'écart se situe entre ces deux-là.
Si les deux échouent, regardez la politique de sécurité du point de terminaison et l'adresse source qu'il voit réellement. Un redirecteur derrière NAT présente l'adresse NAT plutôt que l'adresse VPN du portable, et cette différence suffit à elle seule à faire tomber la requête. Si les deux réussissent mais que l'application échoue encore, l'application utilise peut-être un résolveur différent de celui que vous avez testé.
Gardez les espaces de noms public et privé séparés à dessein. Le DNS fractionné est une politique que vous configurez, pas un effet secondaire d'une requête qui renvoie des données par hasard.
Ce que je ne ferais pas
Je n'ajouterais pas une règle NAT qui a fait fonctionner une seule requête pour appeler cela une conception.
Je ne pointerais pas tous les clients distants vers l'adresse plus deux parce qu'un test a renvoyé un enregistrement une fois. Et je n'élargirais pas la politique de sécurité du point de terminaison à tout le pool VPN alors qu'un seul redirecteur a besoin d'accès. Si l'organisation exploite déjà un redirecteur approuvé dans le VPC, lisez cette conception d'abord, car le deuxième point de terminaison que vous ajoutez est celui que personne ne documente.