@jrEngineerSoJr

Как разрешить доступ к MS SQL (named instance) серверу за WIndows Firewall?

Есть машина с Windows Server 2019 Datacenter, запущен встроенный фаервол, на это сервере поднят MS SQL 2016. Сервер заведен в домен.
С другой машины домена соединиться с MS SQL не удается, при поиске Browse for more-Network servers его тоже не видно.
При отключении файрвола на сервере, соединение с MS SQL проходит, в Browse.. тоже все находится.

На сервере при включенном файрволе пробовал:
1) создавать Inbound правило для процесса MS SQL C:\Program Files\...sqlservr.exe.
2) создавать Inbound правило для динамического порта на котором в данный момент работает SQL сервер (Sql Server Configuration Manager->Protocols For #NamedInstance->TCP/IP->IPall->TCP Dynamic Ports).
3) отключать динамические порты MS SQL, задавать статический порт 1433 в IPall и создавать Inbound правило для портов 1433, 1434
Все вышеприведенные попытки результата не принесли, только отключение файрвола давало коннект.

Просьба подсказать в каком направлении смотреть.
  • Вопрос задан
  • 1200 просмотров
Пригласить эксперта
Ответы на вопрос 2
mindtester
@mindtester
http://iczin.su/hexagram_48
https://learn.microsoft.com/ru-ru/sql/sql-server/i...

ps все еще веселее. там есть конфигуратор служб/протоколов. можно назначать алиасы и двигать порты для каждого инстанса/протокола

pps ну и в конекшенстрингах можно указывать сдвинутые порты

ppps к примеру, sqlexpress, алиасом "." в инстанс по дефолту. хотя вопросы с портами это не решает
Ответ написан
Комментировать
igolets
@igolets
Программист C#, MSSQL
Пробовали подключаться телнетом на заданный порт (1433)? Я этот метод использую для точечной проверки наличия доступа.
У меня обычно процедура такая — включаю на сервере доступ по TCP-IP, задаю порт 1433, открываю его на firewall. После этого простая универсальная проверка, не требующая дополнительного ПО — это telnet <адрес> 1433, потом Excel.

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

Что ещё (кроме telnet) я бы посоветовал проверить:
1. Есть ли в firewall инструменты проверки, "что пошло не так". Например, VipNet такое умеет.
2. На клиентской машине запустить CliConfg.exe и посмотреть, может, какие-то настройки на машине откуда-то взялись. Например, настроен алиас, который в явном виде использует named pipes.
3. Можно выключить firewall, открыть подключение и посмотреть в netstat, как именно клиент подключился.
4. Сделать пинг по имени и убедиться, что используется IPv4
5. Попробовать подключение по IP вместо имени.
6. Включить на сервере SQL Browser и открыть соответствующий порт. Иногда помогает :)
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы