Ne pas se connecter à SQL Server sur VPN
Je me suis connecté pour la première fois à un réseau existant via VPN. Je peux envoyer une requête ping à l'adresse IP utilisée par SQL Server à partir du client VPN, mais SSMS ne se connecte pas à SQL Server. J'utilise le bon identifiant et mot de passe.
Pourquoi cela pourrait-il arriver? Des idées ?
Merci
Sur une instance par défaut, SQL Server écoute par défaut sur TCP/1433. Cela peut être changé. Sur une instance nommée, sauf configuration différente, SQL Server écoute sur un port dynamique TCP. Cela signifie que si SQL Server découvre que le port est en cours d'utilisation, il en choisira un autre TCP. La façon dont les clients trouvent généralement le bon port dans le cas d'une instance nommée consiste à parler au service d'écoute SQL Server/au navigateur SQL. Cela écoute sur UDP/1434 et ne peut pas être modifié. Si vous avez un instance nommée, vous pouvez configurer un port statique et si vous avez besoin d'utiliser l'authentification/délégation Kerberos, vous devriez.
Ce que vous devrez déterminer, c'est le port sur lequel votre SQL Server écoute. Ensuite, vous devrez contacter vos responsables réseau/sécurité pour déterminer s'ils autorisent la communication vers ce port via VPN. S'ils le sont, comme indiqué, vérifiez vos paramètres de pare-feu. Certains systèmes ont plusieurs pare-feu (mon ordinateur portable en est un exemple). Si c'est le cas, vous devrez vérifier tous les pare-feu de votre système.
Si tous ces éléments sont corrects, vérifiez que le serveur n'a pas de stratégie IPSEC qui restreint l'accès au port SQL Server via l'adresse IP. Cela pourrait également vous bloquer.
Lorsque cela m'arrive, c'est parce que DNS ne fonctionne pas correctement. Essayez d'utiliser l'adresse IP au lieu du nom du serveur dans la connexion SQL Server.
Assurez-vous que SQL Server est activé pour TCP/IP (quelqu'un l'a peut-être désactivé)?
Cela vous aidera également à vérifier/vérifier le numéro de port utilisé par l'instance SQL (au cas où quelqu'un l'aurait modifié par rapport au port par défaut 1433).
Évidemment, le port 1433 (ou quel que soit le port que SQL écoute) doit être débloqué par les pare-feu entre votre machine et la boîte sur laquelle SQL s'exécute.
Pour vérifier la configuration réseau de SQL (nécessite l'installation des outils clients SQL Server): Démarrer -> Programmes -> SQL Server 200x -> Outils de configuration -> SQL Server Configuration Manager
Connectez-vous à la machine dont vous avez besoin, puis développez l'arborescence (LHS) "Configuration réseau SQL Server", puis choisissez l'instance. Vous devriez avoir quatre options - Mémoire partagée, canaux nommés, TCP/IP et VIA. Vous pouvez vérifier que TCP/IP est activé dans la fenêtre RHS.
Si vous double-cliquez sur TCP/IP et cliquez sur l'onglet "Avancé", vous pouvez également afficher le numéro de port.
Autres réflexions .. Utilisez-vous l'authentification SQL ou l'authentification Windows (domaine)?
Si l'authentification SQL (que je suppose que vous utilisez étant donné le nom d'utilisateur et le mot de passe), êtes-vous sûr que l'instance SQL à laquelle vous vous connectez a activé l'authentification en mode mixte? Sinon, vous devez vous connecter en tant qu'administrateur et modifier les paramètres de sécurité par défaut pour autoriser l'authentification SQL.
Si l'authentification Windows, votre réseau pourrait-il utiliser Kerberos potentiellement? On pourrait penser que les informations d'identification VPN seraient utilisées pour la poignée de main. Je vérifierais que votre compte dispose des droits de connexion appropriés.
Vérifiez que le port utilisé par SQL Server n'est pas bloqué par votre pare-feu ou le VPN.
J'ai également rencontré ce problème lors de la tentative de connexion à distance via le VPN Hamachi. J'avais essayé tout ce qui était disponible sur Internet (y compris ce post) et cela ne fonctionnait toujours pas. Notez que tout a bien fonctionné lorsque la même base de données a été installée sur une machine sur mon réseau local. Enfin, j'ai pu réussir 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émarrez SQL Server Configuration Manager, développez SQL Server Network Configuration, sélectionnez "Protocols for SQLEXPRESS" (ou "MSSQLSERVER"), cliquez avec le bouton droit sur TCP/IP, dans la boîte de dialogue résultante, accédez à 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). Arrêtez puis démarrez les services SQL Server. Après cela, assurez-vous que le pare-feu sur la machine distante est désactivé ou qu'une exception est autorisée pour le port 1433 qui inclut à la fois le sous-réseau local et le sous-réseau pour l'adresse notée dans la boîte de dialogue précédente. Sur votre ordinateur local, vous devriez pouvoir vous connecter en définissant le nom du serveur sur 192.168.1.22\SQLEXPRESS (ou [ip address of remote machine]\[SQL server instance name]).
J'espère que cela pourra aider.
J'ai beaucoup ce problème avec Citrix Access Gateway. J'obtiens généralement une erreur de temporisation. Si vous pouvez 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, car elles traitent toutes des problèmes côté serveur.
Je peux me connecter lorsque j'augmente le délai d'expiration de la valeur par défaut (15 secondes) à 60 secondes, et pour faire bonne mesure, forcez le protocole à TCP/IP. Ces opérations peuvent être effectuées sur l'écran Options de la boîte de dialogue de connexion:
C'est ce qui a résolu 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
Ensuite, j'ai cliqué sur la NOUVELLE instance de serveur et double-cliqué sur le protocole TCP/IP [J'avais également précédemment activé cette option et redémarré le serveur mais cela ne l'a toujours pas corrigé]
maintenant que le TCP/IP était activé, j'ai remarqué que tous les emplacements de port IP de l'onglet "Adresses IP" de la boîte de dialogue avancée Propriétés TCP/IP étaient définis sur Activé = Non.
J'étais curieux de savoir pourquoi ma nouvelle installation définissait tous ces emplacements IP sur NON plutôt que sur Oui, alors je les ai simplement changés en OUI.
Maintenant, la connexion au serveur via VPN fonctionne très bien, je n'ai changé aucun numéro de port.
Remarque: J'ai également désinstallé SQL Server 2008 par défaut de Visual studio 2010, mais je ne pense pas que cela ait eu un effet direct sur la situation TCP/IP. Un collègue m'a dit que les installations de 2008 et 2005 fournies avec Visual Studio peuvent interférer avec SQL 2012.
Tant que le pare-feu est défini pour autoriser le port utilisé par votre instance SQL Server, il vous suffit de changer la source de données de =Server name à =IP,Port
c'est-à-dire, dans la chaîne de connexion, utilisez quelque chose comme ça.
Data Source=190.190.1.100,1433;
Vous ne devriez rien changer du côté client.
Vous n'avez peut-être pas le port UDP ouvert/transmis par VPN, c'est le numéro de port 1433.
Malgré le nom du protocole client "TCP/IP", mssql utilise UDP pour le bitbanging.
SQL Server utilise le port TCP 1433. Celui-ci est probablement bloqué soit par le tunnel VPN, soit par un pare-feu sur le serveur.
Lorsque vous vous connectez à VPN, chaque message passe par le serveur VPN et il ne peut pas transférer vos messages vers ce port sur lequel le serveur SQL travaille.
Essayer
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 allez d'abord essayer de connecter l'IP locale du serveur SQL et ensuite utiliser le serveur VPN pour vous transférer
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 cingler. Après avoir été frustré qu'aucune méthode d'authentification ne fonctionnerait - j'ai installé un serveur SSH sur le serveur SQL - et j'ai pu me connecter normalement. Cela a confirmé que le bon port n'était pas atteint pour une raison quelconque. J'ai même créé de nouveaux comptes d'utilisateurs, des comptes de domaine, des vérifications de pare-feu aux deux extrémités, etc.
La solution pour moi était: 1. Définissez Connection pour utiliser strictement TCP/IP sur SSMS 2. Utilisez une chaîne personnalisée pour pointer vers le port par défaut (ex: Data Source = 192.168.168.166,1433;)
Tous les autres commentaires ci-dessus n'ont pas fonctionné jusqu'à présent. Il semble qu'il était obligatoire d'inclure le port (même si sa valeur par défaut).
si vous utilisez SQL Server 2005, démarrez d'abord le service de navigation du serveur SQL