SQL via VPN : client direct ou poste de travail interne ?

Les équipes veulent SSMS sur leurs portables, et la solution rapide consiste à publier le port SQL dans le pool VPN. La réponse plus lente demande où le processus client doit s'exécuter, car l'accès direct et un poste de travail interne produisent des adresses source, une confiance du point de terminaison et des chemins de données différents. Aucun des deux n'est automatiquement sûr, et l'appartenance au VPN ne décide rien à elle seule. Comparez les conceptions avant qu'une règle d'autorisation n'existe.

Deux chemins, deux adresses source

En accès direct, le portable porte la configuration du client et ouvre lui-même la connexion à la base. Avec un poste distant, le portable ouvre une session de bureau, et le poste établit la connexion SQL depuis sa propre adresse. La base voit donc le pool VPN ou une passerelle traduite dans la première conception, et l'adresse du poste dans la seconde. Cette différence décide quelle règle de pare-feu et quelle permission SQL s'appliquent réellement.

Le portable contrôle toujours la session distante, un poste ne remplace donc pas l'authentification utilisateur ni la politique de session.

Vérifiez ce que la base voit réellement

L'adresse source se mesure, elle ne se déduit pas d'un schéma. Lisez-la côté serveur d'une connexion active.

Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"

Le test de connectivité prouve que l'écouteur accepte TCP depuis ce réseau, tandis que la requête prouve quel identifiant et quelle base la session a atteints. Pour voir l'adresse enregistrée par le serveur, interrogez sys.dm_exec_connections pour la session en cours, ce qui renvoie l'adresse du client après toute traduction. Si cette valeur est une passerelle et non le portable, une règle d'hôte par utilisateur ne peut pas fonctionner sur la machine de base de données. Notez la valeur observée à côté de la conception choisie, car les reconnexions et les changements de pool la déplacent.

Ouvrez l'écouteur et rien de plus

N'ouvrez que le service dont le déploiement a besoin. Le fameux 1433 est le port de l'instance par défaut, pas une constante universelle.

Get-NetTCPConnection -State Listen -LocalPort 1433

Les instances nommées écoutent souvent sur un port dynamique, avec SQL Server Browser qui répond à la découverte sur UDP 1434, et cette dépendance est une exposition distincte à justifier. Épingler un port fixe pour l'instance supprime le besoin de Browser et rend les règles de pare-feu stables. Conservez les contrôles de chiffrement et de certificat déjà effectués par le client au lieu de les désactiver pour faire passer un test. Accordez ensuite des rôles de base de données pour la charge de travail au lieu d'ajouter tout le groupe VPN à un rôle de serveur.

Prouvez le chemin autorisé et le chemin refusé

Ouvrez une nouvelle session en tant qu'utilisateur ordinaire approuvé, et confirmez l'identité du serveur, la base et l'opération requise. Confirmez ensuite l'exclusion : une source ou un compte hors politique doit échouer au même test. Pour la conception avec poste de travail, vérifiez que le portable ne peut pas contourner la frontière en atteignant directement la base. Pour l'accès direct, vérifiez que la route et la règle de source tiennent toujours après une reconnexion.

Notez où le client s'est exécuté, quelle source la base a observée et quelle règle l'a autorisé. C'est la preuve que la prochaine revue demandera.