Ne pas se connecter à un serveur SQL via VPN
je me suis connecté pour la première fois à un réseau existant via VPN. Je peux effectuer un ping de l'adresse IP qui est utilisée par le serveur SQL depuis le client VPN, mais SSMS ne se connecte pas au serveur SQL. J'utilise le bon nom d'utilisateur et mot de passe.
pourquoi cela a-t-il pu se produire ? Des idées ?
Merci
13 réponses
sur une instance par défaut, SQL Server écoute TCP / 1433 par défaut. Ceci peut être changé. Sur une instance nommée, à moins qu'elle ne soit configurée différemment, SQL Server écoute un port TCP dynamique. Cela signifie que si SQL Server découvre que le port est utilisé, il choisira un autre port TCP. Comment les clients trouvent habituellement le bon port dans le cas d'une instance nommée est en parlant au Service D'écoute du serveur SQL/navigateur SQL. Cela écoute UDP / 1434 et ne peut pas être changé. Si vous avez un nom de exemple, vous pouvez configurer un port statique et si vous avez besoin d'utiliser l'authentification Kerberos/délégation, vous devriez.
ce que vous devez déterminer est le port sur lequel votre serveur SQL écoute. Ensuite, vous aurez besoin d'obtenir avec vos gens de réseautage/sécurité pour déterminer s'ils permettent la communication à ce port via VPN. Si elles le sont, comme indiqué, vérifier vos paramètres de pare-feu. Certains systèmes ont plusieurs pare-feu (mon portable est un exemple). Si oui, vous aurez besoin de vérifier toutes les pare-feu sur votre système.
si toutes ces réponses sont correctes, vérifiez que le serveur N'a pas de politique IPSEC qui restreint l'accès au port du serveur SQL via l'adresse IP. Cela pourrait aussi vous bloquer.
Quand cela m'arrive, c'est parce que le DNS ne fonctionne pas correctement. Essayez d'utiliser l'adresse IP au lieu du nom du serveur dans le login du serveur SQL.
assurez-vous que SQL Server est activé pour TCP/IP (quelqu'un peut l'avoir désactivé)?
cela vous aidera également à vérifier le numéro de port que L'instance SQL utilise (au cas où quelqu'un l'aurait modifié par défaut du port 1433).
évidemment le port 1433 (ou n'importe quel port sur lequel SQL écoute) doit être débloqué par n'importe quel pare-feu entre votre machine et la boîte sur laquelle SQL tourne.
pour vérifier la configuration réseau de SQL (nécessite le Client SQL Server) Installer les outils de): Démarrer -> Programmes -> SQL Server 200x -> Outils de Configuration -> Gestionnaire de Configuration SQL Server
connectez-vous à la machine dont vous avez besoin puis développez L'élément de L'arbre (LHS) "SQL Server Network Configuration", puis sélectionnez instance. Vous devriez avoir quatre options-la mémoire partagée, les Pipes nommées, TCP/IP et VIA. Vous pouvez vérifier que TCP/IP est activé dans la fenêtre RHS.
si vous double-cliquez TCP / IP et cliquez sur L'onglet" Avancé", vous pouvez également voir le Port nombre.
autres réflexions.. Utilisez-vous L'authentification SQL ou Windows (domaine)?
si L'authentification SQL (que je suppose que vous utilisez étant donné que vous avez dit nom d'utilisateur et mot de passe), êtes-vous sûr que L'instance SQL dans laquelle vous vous connectez a activé l'authentification en mode mixte? Si ce n'est pas le cas, vous devez vous connecter en tant qu'administrateur et modifier les paramètres de sécurité par défaut pour permettre L'authentification SQL.
Si Windows Authentification, votre réseau pourrait-il utiliser Kerberos? On pourrait penser que les accréditations VPN seraient utilisées pour la poignée de main. Je vérifierais que votre compte a les droits de connexion appropriés.
Vérifiez que le port que SQL Server n'est pas bloqué par votre pare-feu ou VPN.
j'ai aussi eu ce problème en essayant de me connecter à distance via le VPN Hamachi. J'avais essayé tout ce qui était disponible sur internet (y compris ce billet) et cela n'a toujours pas fonctionné. Notez que tout a bien fonctionné lorsque la même base de données a été installée sur une machine de mon réseau local. Enfin, j'ai réussi à atteindre le succès en utilisant le correctif suivant: sur la machine distante, activez l'adresse IP sur le protocole TCP/IP, comme ceci:
sur la machine distante, démarrer le serveur SQL Gestionnaire de Configuration, étendre la Configuration réseau du serveur SQL, sélectionnez "protocoles pour SQLEXPRESS" (ou "MSSQLSERVER"), cliquez avec le bouton droit de la souris sur TCP/IP, sur la boîte de dialogue résultante, allez à L'onglet Adresses IP, et assurez-vous que l'élément "IP1" est Active=Yes et Enabled=Yes. Notez l'adresse IP (pour moi, il n'était pas nécessaire de les modifier). Puis arrêter et démarrer les Services du serveur SQL. Après cela, assurez-vous que le pare-feu de la machine distante est désactivé, ou qu'une exception est permise pour le port 1433 qui comprend à la fois le sous-réseau local et le sous-réseau pour l'adresse indiquée dans la boîte de dialogue précédente. Sur votre machine locale, vous devriez pouvoir vous connecter en définissant le nom du serveur à 192.168.1.22\SQLEXPRESS (ou [ip address of remote machine]\[SQL server instance name]).
j'Espère que vous aide.
vous ne pouvez pas avoir le port UDP ouvert / VPN-forwarded, c'est le numéro de port 1433.
malgré le nom de protocole client de "TCP / IP", mssql utilise UDP pour bitbanging.
SQL Server utilise le port TCP 1433. C'est probablement bloqué soit par le tunnel VPN ou par un pare-feu sur le serveur.
lors de la connexion à VPN chaque message passe par le serveur VPN et il ne peut pas être rediriger vos messages vers le port sur lequel le serveur SQL travaille.
désactiver les paramètres VPN->propriétés->propriétés TCP/IP->avancé- > utiliser la passerelle par défaut sur le réseau distant.
de cette façon, vous essaierez d'abord de connecter L'IP locale de SQL server et ensuite d'utiliser VPN server pour vous transmettre
j'ai ce problème avec beaucoup de Citrix Access Gateway. J'ai l'habitude d'avoir une erreur de timeout. Si vous êtes en mesure de vous connecter à la base de données à partir d'un client sur le réseau, mais pas à partir d'un client distant via VPN, vous pouvez oublier la plupart des suggestions données ici, parce qu'ils traitent tous des problèmes côté serveur.
je peux me connecter quand j'augmente le délai par défaut (15 secondes) à 60 secondes, et pour une bonne mesure, forcer le protocole à TCP/IP. Ces choses peuvent être faites sur les Options l'écran de la boîte de dialogue de connexion:
c'est ce qui a corrigé mon problème de connexion d'accès à la base de données SQL Server 2012 via VPN
avec le Gestionnaire de Configuration SQL Server 2012,
je suis allé à la configuration du Réseau SQL Server
puis cliqué sur l'instance du nouveau serveur et double-cliqué sur le protocole TCP/IP [J'avais déjà activé cette option et redémarré le serveur mais cela ne l'a toujours pas corrigé]
maintenant que le protocole TCP / IP a été activé, j'ai noté que tous les emplacements de ports IP dans l'onglet "Adresses IP" de la boîte de dialogue Propriétés TCP/IP avancées ont été positionnés à Enabled=No.
j'étais curieux de savoir pourquoi ma nouvelle installation mettait tous ces slots IP à non plutôt que oui, donc je les ai juste changés en YES.
maintenant la connexion au sever via VPN fonctionne très bien, je n'ai pas changé de numéro de port.
Note: J'ai également eu la valeur par défaut SQL Server 2008 de Visual studio 2010 désinstallé, mais je ne pense pas que cela avait un effet direct sur la situation TCP/IP. Un collègue m'a dit que les installations 2008 et 2005 qui viennent avec visual studio peuvent interférer avec SQL 2012.
tant que vous avez le pare-feu défini pour autoriser le port que L'instance de votre serveur SQL utilise, tout ce que vous devez faire est de changer la Source de données de =Server name=IP,Port
ie, dans la chaîne de connexion utilisez quelque chose comme ceci.
Data Source=190.190.1.100,1433;
vous ne devriez pas avoir à changer quoi que ce soit du côté du client.
J'avais aussi ce problème avec SQL Server 2017.
je suis sur le même réseau que le serveur via VPN et je peux le ping. Après avoir été frustré qu'aucune méthode d'authentification ne fonctionnerait - j'ai mis en place un serveur SSH sur le serveur SQL - et j'ai pu me connecter normalement. Cela confirme que le port correct n'a pas été touché pour une raison quelconque. J'ai même créé de nouveaux comptes utilisateurs, des comptes de domaine, des contrôles par pare-feu aux deux extrémités, etc...
La solution pour moi est: 1. Définir la connexion pour utiliser strictement TCP / IP sur les SSM 2. Utiliser une chaîne personnalisée pour pointer vers le port par défaut (ex: Source de Données=192.168.168.166,1433;)
Tous les autres commentaires ci-dessus n'ont pas bien fonctionné jusqu'à présent. Il semble qu'il était obligatoire d'inclure le port (même par défaut).