Не подключается к SQL Server через VPN

Я впервые подключился к существующей сети через VPN. Я могу пинговать IP-адрес, который используется SQL Server из VPN-клиента, но SSMS не подключается к SQL Server. Я использую правильный логин и пароль.

Почему это могло произойти ? Есть идеи ?

спасибо

13 ответов


в экземпляре по умолчанию SQL Server прослушивает TCP / 1433 по умолчанию. Это можно изменить. В именованном экземпляре, если он не настроен иначе, SQL Server прослушивает динамический TCP-порт. Это означает, что если SQL Server обнаружит, что порт используется, он выберет другой TCP-порт. Как клиенты обычно находят правильный порт в случае именованного экземпляра, разговаривая со Службой прослушивателя SQL Server / браузером SQL. Это слушает UDP / 1434 и не может быть изменено. Если у вас есть имя экземпляр, вы можете настроить статический порт, и если вам нужно использовать аутентификацию/делегирование Kerberos, вы должны.

вам нужно определить, какой порт прослушивает ваш SQL Server. Затем вам нужно будет связаться с вашими людьми сети / безопасности, чтобы определить, разрешают ли они связь с этим портом через VPN. Если они, как указано, проверьте настройки брандмауэра. Некоторые системы имеют несколько брандмауэров (например, мой ноутбук). Если это так, вам нужно будет проверить все брандмауэры в вашей системе.

Если все они верны, убедитесь, что сервер не имеет политики IPSEC, которая ограничивает доступ к порту SQL Server через IP-адрес. Это также может привести к блокировке.


когда это происходит со мной, это потому, что DNS работает неправильно. Попробуйте использовать IP-адрес вместо имени сервера в имени входа SQL Server.


убедитесь, что SQL Server включен для TCP / IP (кто-то, возможно, отключил его)?

Это также поможет вам проверить / проверить номер порта, используемый экземпляром SQL (в случае, если кто-то изменил его с порта по умолчанию 1433).

очевидно, что порт 1433 (или любой порт SQL прослушивает) должен быть разблокирован любыми брандмауэрами между вашей машиной и окном SQL.

для проверки конфигурации сети SQL (требуется клиент SQL Server Установлены средства ): Пуск - > Программы - > SQL Server 200x - > средства настройки - > диспетчер конфигурации SQL Server

подключитесь к машине, затем разверните элемент дерева (LHS) "конфигурация сети SQL Server", затем выберите экземпляр. У вас должно быть четыре варианта - общая память, именованные каналы, TCP/IP и VIA. Вы можете проверить, что TCP/IP включен в окне RHS.

Если вы дважды щелкните TCP / IP и нажмите вкладку" Дополнительно", вы также можете просмотреть порт число.

другие мысли.. Вы используете проверку подлинности SQL или проверку подлинности Windows (домен)?

  • Если аутентификация SQL (которую, я полагаю, вы используете, учитывая, что вы сказали имя пользователя и пароль), вы уверены, что экземпляр SQL, к которому вы подключаетесь, включен смешанный режим аутентификации? Если нет, необходимо подключиться как администратор и изменить параметры безопасности по умолчанию, чтобы разрешить проверку подлинности SQL.

  • Если Windows Проверка подлинности, может ли ваша сеть может использовать Kerberos? Можно было бы подумать, что учетные данные VPN будут использоваться для рукопожатия. Я бы проверил, что у вашей учетной записи есть соответствующие права входа.


убедитесь, что порт, используемый SQL Server, не блокируется брандмауэром или VPN.


у меня также была эта проблема при попытке удаленного подключения через Hamachi VPN. Я пробовал все, что доступно в интернете (включая этот пост), и это все еще не сработало. Обратите внимание, что все работало нормально, когда одна и та же база данных была установлена на компьютере в моей локальной сети. Наконец, я смог добиться успеха, используя следующее исправление: на удаленной машине включите IP-адрес по протоколу TCP/IP, например:

на удаленной машине запустите SQL Server Configuration Manager, разверните узел конфигурация сети SQL Server, выберите "протоколы для SQLEXPRESS" (или "MSSQLSERVER"), щелкните правой кнопкой мыши TCP/IP, в появившемся диалоговом окне перейдите на вкладку IP-адреса и убедитесь, что элемент "IP1"Active=Yes и Enabled=Yes. Обратите внимание на IP-адрес (для меня не было необходимости изменять их). Затем остановите и запустите службы SQL Server. После этого убедитесь, что брандмауэр на удаленном компьютере отключен или разрешено исключение для порта 1433, который включает как локальную подсеть, так и подсеть для адреса, указанного в предыдущем диалоговом окне. На вашем локальном компьютере вы сможете подключиться, установив имя сервера в 192.168.1.22\SQLEXPRESS (или [ip address of remote machine]\[SQL server instance name]).

надеюсь, что это поможет.


возможно, у вас нет порта UDP open / VPN-forwarded, это номер порта 1433.

несмотря на имя протокола клиента "TCP / IP", mssql использует UDP для bitbanging.


SQL Server использует TCP-порт 1433. Вероятно, это заблокировано либо туннелем VPN, либо брандмауэром на сервере.


при подключении к VPN каждое сообщение проходит через VPN-сервер, и он не может пересылать ваши сообщения на этот порт, на котором работает SQL server.

попробовать

отключить настройки VPN- > свойства - >свойства TCP / IP->дополнительно->использовать шлюз по умолчанию в удаленной сети.

таким образом, вы сначала попытаетесь подключить локальный IP-адрес SQL server и только затем использовать VPN-сервер для пересылки вам


У меня есть эта проблема с Citrix Access Gateway. Обычно я получаю ошибку тайм-аута. Если вы можете подключиться к базе данных от клиента в сети, но не от удаленного клиента через VPN, вы можете забыть большинство предложений, приведенных здесь, потому что все они касаются проблем на стороне сервера.

Я могу подключиться, когда я увеличиваю тайм-аут от значения по умолчанию (15 секунд) до 60 секунд, и для хорошей меры, принудительно протокол к TCP/IP. Эти вещи можно сделать на вариантах экран диалога входа в систему:

`


это то, что исправило мою проблему подключения к базе данных SQL Server 2012 через VPN

с помощью Диспетчера конфигурации SQL Server 2012,

Я пошел в сетевую конфигурацию SQL Server

затем щелкните новый экземпляр сервера и дважды щелкните протокол TCP/IP [Я также ранее включил эту опцию и перезагрузил сервер, но это все еще не исправило его]

теперь, когда TCP / IP был включен, я отметил что все слоты IP-портов на вкладке "IP-адреса" диалогового окна "Дополнительные свойства TCP/IP" были установлены на Enabled=No.

Мне было любопытно, почему моя новая установка установила все эти слоты IP на нет, а не Да, поэтому я просто изменил их на да.

теперь соединение с sever через VPN отлично работает, я не менял номера портов.

Примечание: у меня также был SQL Server 2008 по умолчанию из Visual studio 2010 удален, но я не думаю, что прямое влияние на ситуацию TCP / IP. Коллега сказал мне, что установки 2008 и 2005, которые поставляются с visual studio, могут мешать SQL 2012.


пока у вас есть брандмауэр, чтобы разрешить порт, который использует экземпляр SQL Server, все, что вам нужно сделать, это изменить источник данных из =Server name to =IP,Port

ie, в строке подключения используйте что-то вроде этого.

Data Source=190.190.1.100,1433;

вам не нужно ничего менять на стороне клиента.


У меня тоже была эта проблема с SQL Server 2017.

Я нахожусь в той же сети, что и сервер через VPN, и могу пинговать его. После разочарования, что никакой метод аутентификации не будет работать - я настроил SSH-сервер на SQL-сервере - и я смог нормально подключиться. Это подтвердило, что правильный порт не был поражен по какой-то причине. Я даже создал новые учетные записи пользователей, учетные записи доменов, проверки брандмауэра на обоих концах и т. д...

решение для меня было: 1. Установите соединение для строгого использования TCP / IP на SSMS 2. Используйте пользовательскую строку, чтобы указать порт по умолчанию (например: источник данных=192.168.168.166,1433;)

все остальные комментарии выше не работает до сих пор. Похоже, что он был обязательным для включения порта (даже если его значение по умолчанию).


Если вы используете sql server 2005, сначала запустите службу браузера sql server