Instance nommée de SQL Server via un VPN : la découverte, pas le port 1433

La plupart des gens traitent un nom d'hôte SQL Server comme une adresse complète, et un VPN comme quelque chose d'autorisé ou non. En pratique, une instance nommée oblige le client à faire une seconde recherche après le DNS, et c'est cette recherche qu'un tunnel casse le plus souvent. Un point de terminaison explicite l'évite, ce qui explique que tcp:host,port puisse fonctionner alors que host\INSTANCE expire. La différence est entre trouver le service et obtenir l'autorisation de l'utiliser.

Le mythe : un nom d'hôte signifie un port

Le nom d'hôte se résout en une adresse, et c'est là que son rôle s'arrête. Une instance nommée ajoute un nom d'instance que le serveur doit traduire en port TCP, et le client ne peut pas le deviner. Le port 1433 est la valeur par défaut d'une instance par défaut, pas une propriété de chaque instance de la machine. Traiter les deux comme la même chose produit le symptôme classique : le ping fonctionne, le DNS fonctionne, le scan du 1433 ne montre rien, et la conclusion est que le réseau bloque SQL.

Une seconde hypothèse échoue de la même manière : qu'ouvrir le TCP 1433 suffit. Si l'instance écoute ailleurs, un 1433 ouvert prouve seulement qu'autre chose est là. Le port doit correspondre à l'écouteur, et l'écouteur est un détail de configuration côté serveur cela s'interroge plutôt que se devine.

Ce que le client fait réellement avec une instance nommée

Après avoir résolu l'hôte, le client envoie une demande de découverte à SQL Server Browser sur UDP 1434 et demande quel port utilise l'instance nommée. Le service de navigateur répond depuis le registre du serveur lui-même, puis le client ouvre une connexion TCP vers ce port. Deux protocoles et deux ports entrent en jeu avant même qu'une connexion soit tentée.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

C'est pourquoi un blocage UDP seul produit un délai d'attente qui ressemble à un hôte mort. Si le service de navigateur est arrêté ou désactivé, la demande de découverte reste sans réponse alors que le moteur de base de données tourne et que son port TCP est ouvert. Si l'instance est configurée avec un port statique, le client demande quand même, sauf si le point de terminaison lui a été donné directement. Chacune de ces défaillances est identique dans le message d'erreur de l'application, et elles demandent des corrections différentes.

Le service de navigateur est une commodité de découverte, pas la base de données. L'arrêter n'arrête pas le moteur, et le démarrer n'ouvre pas le port TCP de l'instance.

Pourquoi le point de terminaison explicite fonctionne quand le nom ne fonctionne pas

Un point de terminaison explicite retire la recherche de la séquence : le client se connecte directement à l'adresse et au port que vous avez indiqués. C'est d'abord un diagnostic, pas automatiquement un correctif permanent, car le port peut changer si l'instance est reconfigurée plus tard en port dynamique. Comparez les deux formes avec le même client et le même compte avant de conclure.

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

Si la forme explicite réussit et que la forme nommée échoue, la découverte est la faille, et vous pouvez choisir comment la combler : autoriser UDP 1434 à travers le tunnel, ou demander à l'administrateur d'épingler un port statique et de documenter le point de terminaison. Les deux sont des décisions délibérées aux coûts de maintenance différents. Ouvrir tous les ports de la plage n'est ni l'une ni l'autre, et c'est l'option qui tend à être proposée à la fin d'une longue journée. Consignez le choix là où vivent les chaînes de connexion.

Si aucune des deux formes ne fonctionne, le problème se situe en amont de la découverte. Vérifiez l'écouteur, la route et la règle d'accès pour le port que l'instance utilise réellement avant d'accuser le service de navigateur.

Après la découverte : authentification et identité sont distinctes

Un échec de connexion est un événement différent d'un délai d'attente, et l'identité VPN ne devient pas une connexion SQL du fait du tunnel. Une fois que le client atteint le bon port, le moteur de base de données applique sa propre authentification et ses propres autorisations. Mélanger les deux étapes dans un seul ticket, c'est ainsi qu'un problème de découverte est attribué à la mauvaise équipe. Lisez le numéro d'erreur avant de changer quoi que ce soit.

Conservez le nom d'hôte documenté si le pilote valide le certificat du serveur, car se connecter par une adresse numérique peut modifier ce contrôle au lieu de résoudre le problème d'origine. Les pilotes Microsoft récents chiffrent par défaut, si bien qu'une incohérence de nom apparaît comme une erreur de certificat après une connexion TCP réussie. C'est un progrès et non un nouvel échec.

Le mythe à abandonner est qu'un nom d'hôte SQL Server soit une adresse complète. C'est un hôte plus, pour une instance nommée, une recherche que le tunnel peut ne pas transporter. Nommez le port, nommez le chemin de découverte, et la prochaine défaillance vous dira quelle couche corriger.