Tl; Dr
У меня есть экземпляр SQL Server (SQLSERVER01-i01) с выделенным IP-адресом и портом (162.xxx.xxx.51: 1433) на множественном экземпляре SQL Server (каждый экземпляр SQL Server на Windows Server имеет свой собственный IP-адрес ) которые все работают на одном сервере Windows (SQLSERVER01 / 162.xxx.xxx.50).
У меня также есть выделенный экземпляр служб Reporting Services (SQLSERVERRS01-i01) с собственным IP-адресом и портом (168.xxx.xxx.71: 1433), который работает на другом сервере Windows (SQLSERVERRS01) с собственным IP-адресом (168 .xxx.xxx.70).
На выделенном сервере служб Reporting Services есть приложение, к APPL1которому можно обратиться как через, так http://SQLSERVERRS01-i01:80/Reports_APPL1и через него http://SQLSERVERRS01:80/Reports_APPL1.
SSRS примет оба запроса из-за *:80конфигурации в конфигурации служб Reporting Services для заголовков узлов.
У нас есть несколько брандмауэров между каждым диапазоном IP-адресов, что означает, что мы должны подать заявку на определенное правило для каждого IP-IP-соединения или IPrange-IP-соединения. Однако, когда задействованы два сервера, безопасность диктует, что в брандмауэре всегда должно быть правило IP-to-IP.
Вопрос
(основано на снимке экрана ниже)
Когда сервер служб Reporting Services подключается к экземпляру SQL Server (162.xxx.xxx.51) для получения данных, он всегда будет устанавливать соединение с базовым IP-адресом сервера Windows (168.xxx.xxx.70 / предпочитаемый ) на котором работает SSRS или будет (иногда) использовать IP-адрес экземпляра служб отчетов SQL Server (168.xxx.xxx.71)?
Это актуально для настройки правила брандмауэра с использованием подхода IP-к-IP. Я либо должен подать заявку на правило, определяющее соединение 168.xxx.xxx.71 - 162.xxx.xxx.51 через порт 1433, либо соединение 168.xxx.xxx.70 - 162.xxx.xxx.51 через порт 1433.
В настоящее время я бы применил оба правила брандмауэра.
Бонусный вопрос
Можно ли настроить сервер служб Reporting Services для связи с выделенным IP-адресом? В данном случае с адресом 168.xxx.xxx.71.
Ответы я не ищу
Я не ищу совета о том, как оптимизировать конфигурацию брандмауэра или как реализовать концепцию зонирования для наших сетей. (Это уже в стадии разработки). Кроме того, меня не интересуют отзывы о том, что наличие SQL Server и SSRS на одном сервере решило бы мои проблемы. Я знаю это и с удовольствием это сделаю, но для стороннего программного обеспечения, необходимого для работы вместе с компонентами SSRS.
Оно работает
Моя конфигурация работает, если я применяю оба правила брандмауэра между экземпляром SSRS и SQL Server.
168.xxx.xxx.71 --> 162.xxx.xxx.51 : 1433
168.xxx.xxx.70 --> 162.xxx.xxx.51 : 1433
Я хочу безопасно сократить одним правилом брандмауэра и убедиться, что все будет работать. (См. Снимок экрана ниже)
Редактировать: статьи, которые я прочитал до сих пор, предлагают мне только второе правило, но нет никакой гарантии.
Статьи, с которыми я уже ознакомился
Вопросы безопасности для
статьи базы установки SQL Server .Настройка брандмауэра Windows для разрешения доступа к SQL Server В
этой статье рассматриваются все другие статьи, касающиеся настройки брандмауэра для SQL Server.Настройка брандмауэра Windows для доступа к
компоненту Database Engine. IP-адреса не используются.Настройка брандмауэра для доступа к серверу отчетов.
Эта статья была довольно интересной:
... но все же ни слова о конфигурации / настройках / настройках IP.Если вы обращаетесь к реляционным базам данных SQL Server на внешних компьютерах или база данных сервера отчетов находится на внешнем экземпляре SQL Server, необходимо открыть порты 1433 и 1434 на внешнем компьютере.
Выбор исходного IP-адреса на многосетевом компьютере Windows
Статьи 5 и 6 были любезно предоставлены мне Джеймсом (dba.se). В настоящее время они кажутся наиболее подходящими ответами. Однако я немного скептически отношусь к тому, что в одной статье упоминается использование нескольких сетевых карт, в то время как у меня есть только один сетевой адаптер с несколькими IP-адресами. Том (dba.se) также участвовал с советами и общими замечаниями.
Почему здесь, а не в dba.stackexchange.com
Сначала я не хотел публиковать этот вопрос на serverfault.com из-за сложной природы вопроса. Вопрос имеет тенденцию быть специфичным для SQL Server, но также и для Windows Server. В конце концов я решил опубликовать это здесь, потому что я думаю, что это Windows Server IP обрабатывает штуковину (из-за потери лучших слов).
Если модератор считает, что я получу лучший ответ на dba.stackexchange.com, тогда перенесите вопрос туда.
Длинное объяснение
В нашей среде у нас есть серверы Windows, на которых размещено несколько экземпляров SQL Server и несколько параметров IP. Мы добавляем сложные конфигурации брандмауэра, выделенные серверы служб отчетов SQL Server (SSRS) и создаем среду, которая выглядит примерно так:
По сути, у нас может быть один Windows Server, работающий до 15 (пятнадцати) экземпляров SQL Server на отдельных IP-адресах. То же самое относится к выделенному экземпляру служб Reporting Services.
Правила брандмауэра
Различные диапазоны IP-адресов в настоящее время не настроены как зоны, что означает, что мы должны настраивать каждое правило брандмауэра независимо как правило IP-to-IP или IPrange-to-IP. Когда задействованы два сервера, безопасность диктует, что это всегда должно быть правило IP-to-IP. Каждый экземпляр SQL Server будет иметь свой собственный набор правил для брандмауэров, участвующих в обмене данными, будь то соединение сервер-сервер или клиент-сервер. Подача заявки на правило брандмауэра в настоящее время занимает четыре-шесть недель ожидания. Уменьшение количества правил брандмауэра уменьшит нагрузку на команду сетевой безопасности.
Конфигурация IP экземпляра SQL Server
Настройка экземпляра SQL Server для получения только по выделенному IP-адресу и порту выполняется путем изменения некоторых параметров в служебной программе диспетчера конфигурации SQL Server. Первым шагом является запуск в Кoнфигурировании диспетчера SQL Server и в левой части выберите Конфигурация сетевого сервера SQL | Протоколы для InstanceName . На левой панели щелкните левой кнопкой мыши имя протокола TCP / IP и включите протокол. Затем снова щелкните левой кнопкой мыши по протоколу и откройте окно Свойства для TCP / IP .
Затем убедитесь, что в реестре протокола установлены следующие параметры :
Enabled : Yes
Listen All : No
В реестре IP-адресов проверьте следующие параметры для рассматриваемого IP-адреса (например, для сервера служб отчетов в этом примере это будет для 168.xxx.xxx.71)
Active : Yes
Enabled : Yes
IP Address : 168.xxx.xxx.71
TCP Dynamic Ports :
TCP Port : 1433
Примечание. Важно, чтобы настройка динамических портов TCP была пустой, а не просто 0 (ноль).
Теперь у вас есть экземпляр SQL Server, который будет принимать соединения с базой данных только на 168.xxx.xxx.71, используя порт 1433.
Сводная информация об экземпляре SQL Server
Служба браузера SQL Server не работает, и каждый отдельный экземпляр SQL Server настроен на использование только своего собственного IP-адреса на порту 1433. При наличии экземпляра SQL Server с именем GENERAL, сервера Windows с именем хоста SQLSERVER01 и двумя IP-адресами 162.xxx .xxx.50 (хост) и 162.xxx.xxx.51 (экземпляр SQL) Я получу следующие элементы конфигурации:
Windows Server : SQLSERVER01
Windows Server IP : 162.xxx.xxx.50
SQL Server Instance : SQLSERVER01-i01 (DNS A record)
SQL Server Instance : GENERAL (can only be used on the host itself)
SQL Server IP/Port : 162.xxx.xxx.51:1433
SQL Server не будет принимать запросы для 162.xxx.xxx.50: 1433, поскольку ни один экземпляр SQL Server не настроен для прослушивания этого IP-адреса в служебной программе диспетчера конфигурации SQL Server. SQL Server будет принимать запросы только для SQLSERVER01-i01 (на порту 1433) или 162.xxx.xxx.51,1433.
Сводка экземпляра служб отчетов SQL Server
Служба обозревателя SQL Server не работает, и каждый отдельный экземпляр служб отчетов SQL Server настроен на использование только своего собственного IP-адреса на порту 1433. Учитывая экземпляр служб отчетов SQL Server под названием GENERAL, сервер Windows с именем узла SQLSERVERRS01, приложение на именованных SSRS APPL1и двух IP-адресах 168.xxx.xxx.70 (хост) и 168.xxx.xxx.71 (экземпляр SQL) я получу следующие элементы конфигурации:
Windows Server : SQLSERVERRS01
Windows Server IP : 168.xxx.xxx.70
SQL Server Instance : SQLSERVERRS01-i01 (DNS A record)
SQL Server Instance : GENERAL (can only be used on the host itself)
SQL Server IP/Port : 168.xxx.xxx.71:1433
Reporting Services : http://sqlserverrs01-i01/Reports_APPL1
http://sqlserverrs01/Reports_APPL1
SQL Server не будет принимать запросы для 168.xxx.xxx.70: 1433, поскольку ни один экземпляр SQL Server не настроен для прослушивания этого IP-адреса в служебной программе диспетчера конфигурации SQL Server. SQL Server будет принимать запросы только для SQLSERVER01-i01 (на порту 1433) или 162.xxx.xxx.71,1433.
SSRS будет принимать запросы для http: // sqlserverrs01-i01 / Reports_APPL1 или http: // sqlserverrs01 / Reports_APPL1 из-за конфигурации *: 80 в конфигурации служб Reporting Services для заголовков узлов.
Я надеюсь, что предоставил достаточно информации для тех, кто хочет потратить свое время на написание ответа, и я с нетерпением жду ваших технических деталей и ссылок.
Написан с помощью StackEdit, а затем изменен вручную, чтобы быть совместимым с stackexchange.
история
Редактировать 1 : начальный выпуск
Редактировать 2 : переформатировать для удобства чтения. Перемещено объяснение SF / DB вниз. Добавлено имя хоста для Windows Server
Edit 3 : исправлены неправильные IP-адреса в списке правил брандмауэра.
Редактировать 4 : в некоторых местах слово хостинг было изменено на запущенное (это не виртуализированная среда). Добавлен IP-адрес в одном предложении.
Редактировать 5 : Добавлен список статей, с которыми я уже консультировался и на которые ссылается поддержка.
Редактировать 6 : Раздел «Очистить историю»