SQL Server se lie à une adresse VPN absente au démarrage

Lisez une ligne du journal SQL Server sur une liaison échouée alors que le service tourne encore, et vous avez trouvé une dépendance à l’ordre de démarrage, pas un plantage. Cette combinaison est l’indice : le moteur a démarré avant que l’adresse sur laquelle il devait écouter n’existe sur la machine. Un adaptateur VPN qui apparaît après la connexion est une mauvaise condition préalable pour un service de base de données sans surveillance, alors suivez la défaillance dans l’ordre où le moteur la voit.

Commencez par le journal de démarrage, pas par le client

Ouvrez le journal des erreurs de l’instance et lisez les entrées autour de l’initialisation réseau, pas seulement la dernière ligne. Le moteur indique quelles adresses il a essayées et quels protocoles il a activés, et cet enregistrement date d’avant la connexion du moindre client. Regardez maintenant ce qui existe sur l’hôte à cet instant. Si l’interface qui possède l’adresse configurée n’apparaît qu’après qu’un utilisateur se connecte et lance un client, l’adresse était absente au démarrage et l’échec de liaison est entièrement expliqué.

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

Adaptez le chemin de l’instance à votre installation, et lisez la liste des interfaces avant de conclure. Une adresse qui existe mais appartient au mauvais adaptateur est un problème différent d’une adresse qui n’existe pas encore.

Parcourez l’ordre de liaison que le moteur suit réellement

Le moteur lit sa configuration d’écoute, puis demande au système d’exploitation de se lier. Si l’adresse n’est pas locale à cet instant, la liaison échoue pour cette adresse tandis que le reste de l’instance peut continuer normalement. C’est pourquoi d’autres protocoles ou d’autres adresses peuvent encore fonctionner, et pourquoi « SQL Server est en panne » est le mauvais résumé. Conservez le point de terminaison exact du journal : adresse, port et protocole, car le correctif dépend duquel des trois est faux.

Redémarrer le service après l’apparition de l’adaptateur fera généralement réussir l’écouteur, et c’est précisément le piège. Cela prouve la dépendance au lieu de la supprimer, et cela coupe chaque utilisateur connecté à chaque reconnexion du tunnel.

Lisez l’écouteur comme le moteur le lit

Dans SQL Server Configuration Manager, ouvrez les propriétés TCP/IP de l’instance et notez le réglage Listen All avant de modifier des adresses individuelles. Quand Listen All est sur Yes, les valeurs Enabled par adresse sont ignorées, donc les modifier ne change rien de ce que l’écouteur utilise. Notez trois choses dans l’ordre : l’adresse que vous comptez servir, le port, et si l’écouteur doit couvrir toutes les adresses ou une seule. Appliquez ensuite le changement via la procédure de redémarrage prise en charge et lisez le journal de démarrage suivant pour confirmer que le moteur a lié ce que vous avez demandé.

Écouter sur toutes les adresses n’est pas un contrôle d’accès. Si un écouteur large est réellement nécessaire, chaque interface joignable a besoin de sa propre décision de pare-feu et d’autorisation de base de données, y compris toute interface tournée vers internet.

Donnez au client une destination stable

Le client n’a pas besoin que l’hôte de base de données porte une adresse de pool. Une conception routée fonctionne avec le serveur à l’écoute sur son adresse privée stable, tandis que la passerelle VPN achemine le trafic du client vers lui et rapporte la réponse.

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

Si le client atteint 10.80.0.15, le chemin est prouvé et la base de données n’a plus qu’à autoriser ce client. Sinon, corrigez le routage et le DNS avant de retoucher l’écouteur, car un problème de liaison sur le serveur n’a jamais été la raison pour laquelle un client ne le trouve pas. Ajouter une fausse adresse de pool au serveur, ou une seconde passerelle par défaut pour contenter l’écouteur, crée un nouveau problème réseau par-dessus l’ancien. Gardez l’adressage du serveur statique et laissez le tunnel amener les clients jusqu’à lui.

Vérifiez le point de terminaison utilisé par le client

Terminez par un contrôle au niveau applicatif plutôt que par un test de port. Connectez-vous depuis le client avec le compte utilisé par l’application et lisez les détails de connexion côté serveur, qui montrent l’adresse locale sur laquelle votre session s’est posée.

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

Comparez cette adresse à l’écouteur que vous avez configuré. Un écart signifie un second écouteur ou un nom résolu quelque part d’inattendu, et les deux valent la peine d’être connus avant que le prochain redémarrage ne teste votre correctif à votre place. Redémarrez ensuite l’hôte sans aucun utilisateur connecté et confirmez que la liaison réussit. Ce seul test fait la différence entre un écouteur réparé et un contournement qui échoue lors de la prochaine nuit de correctifs.