Azure P2S VPN ne résout pas le nom d'un point de terminaison privé

Vous connectez le tunnel point à site, vous pingez l'adresse privée, vous ouvrez l'application et vous obtenez à la place un 403 ou une erreur de certificat. Les deux symptômes pointent vers DNS, mais ce sont des pannes différentes : l'un signifie que le client a résolu l'adresse publique, l'autre qu'il a résolu l'adresse privée puis proposé un nom que le certificat ne couvre pas. Faites les contrôles ci-dessous dans l'ordre et arrêtez-vous au premier échec, car une entrée hosts ou une réponse en cache peut faire réussir chaque contrôle suivant pour la mauvaise raison. Je garde cet ordre dans un fichier texte à côté de mes profils VPN, car la correction ne change rien au tunnel et change tout à ce que le client sait.

Commencez par l'adresse que le client reçoit réellement

Interrogez le résolveur directement au lieu de faire confiance à l'application. Sous Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net montre quelle vue le client a reçue. Une réponse publique signifie que rien en aval n'atteindra le point de terminaison ; l'adresse privée du point de terminaison signifie que DNS est terminé et que le contrôle suivant est la connexion elle-même.

Un point de terminaison privé ne renomme pas le service. Le compte ou l'application conserve son nom complet habituel, et le point de terminaison ne change que l'adresse vers laquelle ce nom se résout pour les clients à l'intérieur du réseau virtuel. C'est pourquoi le même nom d'hôte se résout en privé depuis une VM du réseau et en public depuis un portable qui n'a jamais reçu la vue privée.

Vérifiez la zone, son lien et l'enregistrement avant le tunnel

Trois conditions doivent être réunies : la zone privée existe, elle est liée au réseau virtuel par lequel la passerelle VPN et les clients entrent dans Azure, et elle contient un enregistrement A du point de terminaison pointant vers l'adresse privée. Liez la zone à un réseau sans rapport et la passerelle continuera de résoudre l'enregistrement public alors que tout, côté tunnel, semble sain.

Les noms de zone appartiennent aux services, pas aux liaisons privées en général. App Service utilise normalement privatelink.azurewebsites.net, le stockage et SQL ont leurs propres espaces de noms, et emprunter la zone d'un autre service produit une zone qui existe et ne répond rien d'utile.

Donnez au client un résolveur qu'il peut réellement joindre

168.63.129.16 répond depuis des machines virtuelles Azure et n'est pas un serveur DNS pour un portable de l'autre côté d'un tunnel point à site. Le client a besoin d'un résolveur joignable par le tunnel : un point de terminaison entrant d'Azure DNS Private Resolver, un redirecteur à l'intérieur du réseau virtuel, ou des entrées de serveur DNS portées dans le profil du client VPN pour que le client interroge directement le réseau virtuel.

Un résolveur configuré mais injoignable se comporte exactement comme aucun résolveur, et le symptôme est un délai d'attente plutôt qu'une mauvaise réponse, ce qui le fait lire à tort comme un problème de pare-feu. Testez-le avec une requête que le tunnel est censé porter, pas avec un nom public qui aurait de toute façon réussi par le lien local.

Si vous redirigez au lieu de pousser des paramètres, redirigez l'espace de noms que possède la zone privée, privatelink.azurewebsites.net plutôt que tout azurewebsites.net. Un redirecteur conditionnel qui avale tout le suffixe parent envoie vers Azure chaque recherche du service, y compris celles qui devraient rester locales.

Utilisez le nom pour lequel le certificat a été émis

Une fois l'adresse correcte, la seconde panne apparaît. Le stockage et App Service publient un alias privatelink, et cet alias n'est pas forcément le nom du certificat. Un envoi AzCopy adressé à privatelink.blob.core.windows.net a échoué à la validation ; le même envoi vers <account>.blob.core.windows.net/<container> s'est résolu vers l'adresse privée et a réussi, il est donc resté sur le chemin privé sans dérogation.

La règle vaut dans un navigateur et pour App Service aussi : connectez-vous avec le nom d'hôte que le certificat couvre et laissez DNS fournir l'adresse privée. Ne cherchez pas à contourner la validation, car cela transforme une erreur de nommage en régression de sécurité. Un ping réussi prouve la route et ne dit rien du nom à l'intérieur de la poignée de main, c'est pourquoi ces contrôles restent séparés.

Un ordre en quatre étapes qui isole chaque couche

1. Confirmez que le client VPN détient une adresse du pool point à site et une route vers l'adresse privée du point de terminaison.
2. Résolvez le nom exact qu'utilise l'application et comparez la réponse à l'adresse du point de terminaison.
3. Ouvrez une connexion TCP vers le point de terminaison sur le port du service, puis lisez le nom du certificat présenté sur cette connexion.
4. Ne testez l'autorisation que maintenant, car un chemin qui fonctionne et un certificat valide ne donnent pas encore accès à la ressource.

Une connexion refusée alors que l'adresse est correcte désigne le groupe de sécurité réseau ou l'état de connexion du point de terminaison privé, pas DNS, vérifiez-les donc avant de modifier à nouveau les paramètres du résolveur. Un nom TLS qui ne correspond pas vous renvoie au nom d'hôte de l'URL et au sujet du certificat. Gardez ensemble la sortie de résolution, le nom du certificat et l'URL exacte ; ces trois valeurs expliquent la plupart de ces cas sans toucher à la passerelle.

Utilisez une VM à l'intérieur du réseau virtuel comme témoin. Si le nom s'y résout en privé et en public depuis le tunnel, la zone et l'enregistrement sont corrects et la seule différence est le chemin du résolveur du client, ce qui se confirme plus vite qu'une nouvelle passe sur la configuration du point de terminaison.

Les clients mettent aussi en cache. Un enregistrement qui a répondu publiquement il y a dix minutes continue de répondre après la correction de la zone, videz donc le cache avant de retester. Sous Windows, ipconfig /flushdns vide le cache du client ; les règles de stratégie de résolution de noms persistent, décident quel suffixe va à quel serveur et peuvent continuer d'envoyer l'espace de noms au résolveur que vous venez de remplacer.

Où va une entrée hosts

Ajouter l'adresse du point de terminaison dans un fichier hosts est un bon diagnostic et une mauvaise conception. Cela prouve que la correspondance nom-adresse est la pièce manquante et permet de tester tout ce qui suit, mais c'est invisible pour vos utilisateurs, cela casse quand l'adresse du point de terminaison change et cela masque la zone qui devrait répondre.

Une entrée de test oubliée est pire qu'un cache périmé, car elle peut faire paraître cassé le chemin réparé ou réparé le chemin cassé selon le sens de l'erreur. Supprimez-la avant la passe finale et ne résolvez qu'avec le résolveur de production.

Les noms courts ont besoin d'un suffixe de recherche et les noms complets non, testez donc d'abord le nom complet, puis décidez si le flux de travail a besoin d'un suffixe poussé par le profil client. Microsoft documente les noms de zone et les formes d'enregistrement par service dans ses conseils DNS pour les points de terminaison privés ; lisez l'entrée de votre service au lieu de copier une zone d'un autre.