Не подключается к SQL Server через VPN - PullRequest
14 голосов
/ 21 марта 2009

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

Почему это могло случиться? Есть идеи?

Спасибо

Ответы [ 13 ]

12 голосов
/ 21 марта 2009

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

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

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

6 голосов
/ 21 марта 2009

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

4 голосов
/ 21 марта 2009

Убедитесь, что 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 будут использоваться для рукопожатия. Я бы проверил, есть ли у вашей учетной записи соответствующие права входа.

2 голосов
/ 07 ноября 2012

У меня также была эта проблема при попытке удаленного подключения через 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]).

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

2 голосов
/ 21 марта 2009

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

1 голос
/ 08 февраля 2018

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

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

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

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

1 голос
/ 10 марта 2016

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

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

Data Source=190.190.1.100,1433;

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

1 голос
/ 01 января 2014

Это то, что решило мою проблему с подключением к базе данных 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.

1 голос
/ 06 июня 2013

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

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

`

1 голос
/ 21 марта 2009

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

Попробуйте

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

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

...