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

https://stackoverflow.com/questions/669372

21-08-2019
|

Вопрос

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

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

Спасибо

Решение

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

Вам нужно будет определить, какой порт прослушивает ваш SQL-сервер.Затем вам нужно будет связаться со своими специалистами по сети и безопасности, чтобы определить, разрешают ли они связь с этим портом через 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, разверните узел «Конфигурация сети 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 или не перенаправлен VPN, это номер порта 1433.

Несмотря на имя клиентского протокола «TCP/IP», mssql использует UDP для битовой обработки.

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

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

Пытаться

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

Таким образом, вы сначала попытаетесь подключить локальный IP-адрес SQL-сервера и только затем использовать 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» установлено значение «Включено = Нет».

Мне было любопытно, почему в моей новой установке для всех этих IP-слотов установлено значение «НЕТ», а не «Да», поэтому я просто изменил их на «ДА».

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

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

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

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

Data Source=190.190.1.100,1433;

Вам не придется ничего менять на стороне клиента.

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow