#sql-server #ssms #port #windows-defender
Вопрос:
Цель этого поста-выяснить, почему я не могу войти в удаленный экземпляр SQL Server из системы Windows 10. Моя система Windows 10 подключается просто отлично, и в ней слишком много правил противопожарной стены, которые не ограничивают.
Поэтому я хотел бы ужесточить правила входящего и исходящего брандмауэра Windows 10/Защитника Windows, которые, по моему мнению, позволяют среде SQL Server Management Studio взаимодействовать с сервером SQL на удаленном узле. И клиент, и сервер находятся в одном домене.
Экземпляр SQL на удаленном сервере использует динамический порт 49365.
У меня есть входящее правило, неограниченный TCP для локальных и удаленных портов. На какие порты следует сузить это правило?
Для моего правила исходящих сообщений у меня есть протокол UDP для всех локальных портов и удаленного порта 1434.
Я считаю, что эта сумасшедшая конфигурация позволяет среде SQL Management Studio общаться с удаленным SQL-сервером через динамический порт 49365.
Вопросы 1. Какими на самом деле должны быть настройки правил брандмауэра?
(Я собираюсь задать вопрос 2 в качестве отдельной операции.)
Комментарии:
1. Вы спрашиваете о компьютере сервера или о компьютере клиента ? Т. е. тот, на котором работает движок БД, или тот, на котором работает SSMS?
2. Моя проблема в клиенте. Я могу прекрасно использовать студию управления сервером, когда я удален.
Ответ №1:
Во-первых, простая часть: клиенту не требуется входящее соединение, так как он не получает никаких подключений (он их создает), поэтому вы можете безопасно заблокировать все inboud.
Теперь о тех, кто уходит. Самому серверу требуется доступ по протоколу TCP только в том порту, который он прослушивает, поэтому, если у вас есть фиксированный порт, вы просто открываете его (по умолчанию 1433 для экземпляра по умолчанию), и все готово.
Но поскольку вы используете динамические порты, настройка немного сложнее. По сути, «динамический порт» означает, что сервер прослушивает «случайный» порт при каждом запуске, а служба браузера SQL сообщает клиентам, на каком порту прослушивается каждый экземпляр (это настройка по умолчанию для именованных экземпляров).
Поэтому для этого сначала вам нужно разрешить исходящие подключения к браузеру SQL, который прослушивает UDP 1434. Теперь вам также понадобится обычное подключение к серверу, как и раньше, которое по-прежнему работает по протоколу TCP, но на этот раз порт неизвестен (так как он случайный). Таким образом, самое большее, что вы можете сделать, — это разрешить все TCP-порты, возможно, также отфильтрованные клиентской программой (ssms.exe например) или любым другим параметром, который поддерживает ваш брандмауэр.
Ответ №2:
я думаю, что вам нужно создать входящее правило в SQL Server, разрешающее порт 1433/1433 . Динамический порт не важен для этой конфигурации.
Комментарии:
1. Я собираюсь попробовать это и дам вам знать.
2. Я отключил другие правила, которые у меня были, и сделал правило 1433/1433. Спасибо.
3. Это неверно. Поскольку правила входящих сообщений клиента не имеют значения (клиент не получает никаких подключений). Все соединения являются исходящими.