Point de terminaison privé, même nom de serveur : chaînes de connexion Azure SQL

Private Link change l’endroit où aboutit une connexion, pas le nom de la connexion. Pour Azure SQL Database, cette distinction constitue tout le design : le serveur logique conserve son nom, et le point de terminaison privé fournit une entrée réseau vers laquelle le nom se résout. Remplacer le nom par une adresse IP est le seul changement qui casse TLS, les identifiants et les outils en même temps. Deux chaînes de connexion peuvent sembler équivalentes et se comporter de façon totalement différente.

Conservez orders-db.database.windows.net et donnez au client une réponse privée pour celui-ci.

Le nom et l’adresse ont des rôles différents

Le nom identifie le service SQL, et c’est ce que le certificat et la connexion attendent. L’adresse privée fournit une entrée réseau à l’intérieur du réseau virtuel connecté. Confondre l’une avec l’autre produit une connexion qui atteint quelque chose et ne s’authentifie auprès de rien.

Les recommandations Microsoft pour Azure SQL exigent le nom de serveur normal des clients. Une IP directe, et de même le nom préfixé par privatelink, n’est pas une cible de connexion interchangeable. Les outils qui acceptent une IP l’acceptent puis échouent sur TLS ou sur l’authentification, ce qui masque la vraie erreur. Ces échecs se lisent comme des problèmes d’identifiants jusqu’à ce qu’on regarde le nom d’hôte dans l’erreur.

Ce que la zone privée change réellement

La zone DNS privée enregistre une adresse pour le serveur dans l’espace de noms privatelink, et la zone est liée au réseau virtuel qui doit l’utiliser. La résolution se déplace ; la chaîne de connexion non. La forme ci-dessous est une illustration, pas un enregistrement à coller dans une zone publique.

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

Maintenez cet enregistrement et son lien de zone comme infrastructure, avec un responsable et une date de revue.

Deux zones ayant la même origine et des réponses différentes constituent l’état final normal, pas un conflit. Les clients publics conservent la réponse publique, et les clients privés obtiennent l’adresse du point de terminaison. Le mode de défaillance à surveiller est la propagation partielle de la vue privée, où un sous-réseau se résout en privé et un autre, silencieusement, non.

Les clients hors d’Azure ont besoin d’un chemin vers cette zone

Un client VPN se trouve en dehors du résolveur d’Azure, donc la zone privée doit être joignable depuis le chemin hybride. Un redirecteur DNS Azure ou Azure DNS Private Resolver peut servir les requêtes qui arrivent par ce réseau. La recommandation de Microsoft est de transférer la zone de service public concernée via cet arrangement plutôt que de supposer que les clients interrogent directement le nom privatelink. Les clients qui ne peuvent pas résoudre la réponse privée retombent sur la publique sans se plaindre.

Gardez la portée du transfert intentionnelle, car remplacer une zone publique en usage casse des noms que le remplacement ne contient pas.

Provisionnez dans un ordre qui maintient l’identité fixe

Les étapes ont des responsables distincts : créez et approuvez le point de terminaison, fournissez la route VPN, intégrez le DNS privé, puis configurez le client avec son nom de serveur normal. Faire le DNS avant la route produit des délais qui ressemblent à des échecs DNS. Faire le client en dernier maintient une variable en mouvement à la fois. Chaque étape a un résultat observable, donc aucune n’a besoin d’être testée en devinant.

Une icône VPN connectée ne sélectionne pas à elle seule une destination privée.

Ce qu’un point de terminaison privé ne désactive pas

Créer un point de terminaison privé ne désactive pas automatiquement l’accès public au serveur logique. C’est une décision de déploiement distincte, et elle intervient après que les clients privés prévus ont été confirmés fonctionnels. Conservez un chemin de récupération et tenez compte des applications qui utilisent encore l’entrée publique. Désactiver d’abord l’accès public est la façon dont un service qui fonctionne devient une panne avec une piste d’audit bien tenue.

Vérifiez aussi quelle politique de connexion le serveur utilise.

Redirect envoie le client vers un port du nœud après une connexion initiale à la passerelle, ce qui change ce que le réseau client doit autoriser. Proxy maintient le trafic sur la passerelle. Une poignée de main TCP réussie sur un port n’est pas tout le processus de connexion.

Il s’agit d’Azure SQL Database, pas de SQL Managed Instance, qui a son propre modèle de connectivité et aucune histoire équivalente de point de terminaison privé. Dans les deux cas, gardez trois éléments étiquetés séparément : le nom, l’entrée réseau et l’identifiant. Changer par où passe une connexion ne devrait jamais changer le service auquel le client croit parler.