Обработка IP-адресов служб отчетов SQL Server (SSRS) на многоэкземплярных серверах
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-to-IP или IPrange-to-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-to-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 для доступа к ядру СУБД
Ни слова об 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. В конце концов я решил опубликовать это здесь, потому что я думаю, что это вещь, обрабатывающая IP Windows Server (для потери лучших слов).
Если модератор считает, что я получу лучший ответ на dba.stackexchange.com, переместите вопрос туда.
Длинное объяснение
В нашей среде у нас есть серверы Windows, на которых размещено несколько экземпляров SQL Server и несколько настроек IP. Мы добавляем сложные конфигурации брандмауэра, выделенные серверы SQL Server Reporting Services (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 Configuration Manager. Первый шаг - запустить диспетчер конфигурации SQL Server и в левом разделе выбрать Сетевая конфигурация SQL Server | Протоколы для InstanceName. На левой панели щелкните левой кнопкой мыши значок TCP / IP Имя протокола и включить протокол. Затем снова щелкните протокол левой кнопкой мыши и вызовите Свойства для TCP / IP окно.
Затем убедитесь, что в Протокол регистр:
Enabled : Yes
Listen All : No
в IP-адреса register проверьте следующие настройки для рассматриваемого IP-адреса (например, для сервера Reporting Services в этом примере это будет для 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 Configuration Manager. 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.
Редактировать 3: Исправлены неправильные IP-адреса в списке правил брандмауэра.
Редактировать 4: в некоторых местах слово "хостинг" заменено на "запущенный" (это невиртуализированная среда). Добавлен IP-адрес в одном предложении
Редактировать 5: Добавлен список статей, с которыми я уже консультировался, и ссылки на поддержку
Редактировать 6: Очищен раздел истории
Введение
Согласно различным документам, которые я нашел во время своего первоначального исследования, а также документам, представленным в ссылках и обсуждениях, я пришел к прочному, надежному и совместимому решению.
RFC 3484
Бинарные сравнения, проводимые ниже, и применяемые правила соответствуют RFC 3484 что, по-видимому, также справедливо для адресов IPv4.
RFC 3484 также утверждает сразу после Правила 8, что
Rule 8 may be superseded if the implementation has other means of
choosing among source addresses. For example, if the implementation
somehow knows which source address will result in the "best"
communications performance.
Выбор исходного IP-адреса на многодомном компьютере под управлением Windows
Теперь не все правила RFC 3484 применяются к адресам IPv4. Статья в блоге Microsoft Выбор исходного IP-адреса на многодомном компьютере под управлением Windows объясняет, какие правила применяются.
Есть небольшой раздел чуть ниже Поведение Windows Vista / Windows Server 2008 это гласит:
Подобно XP, если программа не указывает исходный IP-адрес, стек обращается к целевому IP-адресу, а затем проверяет всю таблицу IP-маршрутов, чтобы выбрать лучший сетевой адаптер для отправки пакета. После выбора сетевого адаптера стек использует процесс выбора адреса, определенный в RFC 3484, и использует этот IP-адрес в качестве исходного IP-адреса для исходящих пакетов.
Поскольку у меня только одна сетевая карта в экземпляре SQL / SSRS, первая часть спорна. Windows Server всегда будет выбирать единственный доступный сетевой адаптер.
Пока объединение RFC 3484 с блогом Microsoft приводит к тому, что оба IP-адреса являются допустимыми кандидатами на исходный IP-адрес. Объяснение следует ниже в ответе.
Кабельщик
Статья от Cable Guy Кабельщик - модели сильного и слабого хозяина подробно рассказывает о том, как работает выбор IP в Отправка и получение сильного хоста окружающей среде и в Отправка и получение слабого хоста Окружающая среда. Хорошее дополнительное чтение, но не проливает больше света на то, как выбирается исходный IP. Статья относится к уже известному RFC 3484.
Объясняя необъяснимое
Чтобы объяснить решение, мы сначала должны преобразовать рассматриваемые IP-адреса в их двоичные эквиваленты. Поскольку в своем вопросе я не указывал шлюзов, я предполагаю два значения.
Исходные IP-адреса и двоичная запись
Вот список преобразованных двоичных значений для задействованных IP-адресов.
10101000.00000001.00000001.01000110 168.xxx.xxx.070/128 Windows Server
10101000.00000001.00000001.01000111 168.xxx.xxx.071/128 SQL Server / SSRS Instance
10101000.00000001.00000001.00000010 168.xxx.xxx.002/128 Gateway (Assumption 1)
10101000.00000001.00000001.01100010 168.xxx.xxx.100/128 Gateway (Assumption 2)
11111111.11111111.11111111.10000000 255.255.255.128/025 Subnet Mask / CIDR
Целевые IP-адреса и двоичная запись
10101000.00000000.00000000.00110011 168.xxx.xxx.051/128 SQL Server
Пример 1: IP-адрес шлюза ниже IP-адреса экземпляра SQL / SSRS
В этом примере я предполагаю, что IP-адрес шлюза ниже IP-адреса экземпляра SQL Server / SSRS, а именно 168.001.001.002.
Если вы сравните двоичные адреса экземпляра Windows Server и SQL Server / SSRS, то получите следующее:
SQL/SSRS Instance IP
10101000.00000001.00000001.00000010 (Gateway Assumption 1)
10101000.00000001.00000001.01000111 (SQL/SSRS)
-----------------------------------
xxxxxxxx.xxxxxxxx.xxxxxxxx.x------- (x=matching high order bits)
Window Server IP
10101000.00000001.00000001.00000010 (Gateway Assumption 1)
10101000.00000001.00000001.01000110 (Windows)
-----------------------------------
xxxxxxxx.xxxxxxxx.xxxxxxxx.x------- (x=matching high order bits)
Результат Пример 1
В этом примере оба IP-адреса имеют одинаковое количество совпадающих старших битов (или самый длинный совпадающий префикс). До сих пор процесс http.sys будет использовать любой из IP-адресов для исходящей связи.
Пример 2: IP-адрес шлюза выше, чем IP-адрес экземпляра SQL / SSRS
В этом примере я предполагаю, что IP-адрес шлюза выше, чем IP-адрес экземпляра SQL Server / SSRS, а именно 168.001.001.100.
Если вы сравните двоичные адреса экземпляра Windows Server и SQL Server / SSRS, то получите следующее:
SQL/SSRS Instance IP
10101000.00000001.00000001.00000010 (Gateway Assumption 2)
10101000.00000001.00000001.01100010 (SQL/SSRS)
-----------------------------------
xxxxxxxx.xxxxxxxx.xxxxxxxx.x------- (x=matching high order bits)
Windows Server IP
10101000.00000001.00000001.00000010 (Gateway Assumption 2)
10101000.00000001.00000001.01100010 (Windows)
-----------------------------------
xxxxxxxx.xxxxxxxx.xxxxxxxx.x------- (x=matching high order bits)
Результат Пример 2
Несмотря на то, что IP-адрес шлюза теперь выше, чем IP-адрес сервера Windows и экземпляра SQL / SSRS, количество совпадающих старших битов (или самый длинный совпадающий префикс) все равно остается прежним. До сих пор процесс http.sys будет использовать любой из IP-адресов для исходящей связи.
Краткое изложение результатов на данный момент
Пока невозможно сказать, какой IP-адрес будет использовать процесс http.sys для исходящей связи, запущенной на экземпляре SQL / SSRS (.71) на сервере Windows (.70).
«Когда вы устранили невозможное, все, что остается, каким бы невероятным оно ни было, должно быть правдой», - Шерлок Холмс.
Бывают ситуации, когда исходный IP-адрес можно точно указать / выбрать / определить с помощью вышеупомянутых RFC и знаний Microsoft. Но если IP-адреса расположены слишком близко друг к другу и близко к шлюзу, ну, все зависит от удачи. Либо это?
Поскольку я нахожусь в положении создания правил (брандмауэра), а у Microsoft есть ...
реализация (которая) имеет другие средства выбора среди исходных адресов. Например, если реализация каким-то образом знает, какой исходный адрес приведет к «наилучшей» производительности связи.
... тогда все, что мне нужно сделать для определения IP-адреса процесса http.sys состоит в том, чтобы создать только одно правило межсетевого экрана с желаемым IP-адресом.
Что случается
- Я определяю правило брандмауэра от 168.xxx.xxx.71 до 168.xxx.xxx.51: 1433
- Компонент http.sys экземпляра SQL / SSRS соответствует RFC 3484 и выбирает исходный IP-адрес в соответствии с определенными правилами.
- IP-адрес 168.xxx.xxx.71 (на NIC1) определяется как исходный IP-адрес для доступа к IP-адресу 168.xxx.xxx.51 через порт 1433 и, таким образом, назначается всем исходящим пакетам.
Преимущества
- Я никоим образом не вмешиваюсь в реализацию RFC 3484
- Я никоим образом не жонглирую маршрутами или конфигурациями ARP
- Я соблюдаю RFC 3484 и реализацию Microsoft
- Я не взламываю какие-либо настройки реестра или конфигурации системы
- У МЕНЯ НА ОДНО ПРАВИЛО МЕНЬШЕ
Проверка
Мне еще предстоит удалить IP-адрес из правил брандмауэра, но я уверен, что он будет работать так, как было задумано / определено. Резюме будет следовать.
История
Редактировать 1 Начальный пост
Редактировать 2 Почищен ответ, добавлен раздел История
SSRS поддерживает несколько стандартных источников данных, а также другие источники данных .NET:
https://msdn.microsoft.com/en-ca/library/ms159219.aspx
Предполагая, что вы используете собственный клиент SQL для источника данных, у вас нет возможности указать исходный IP-адрес:
Поэтому понятно, что клиент будет использовать IPADDR_ANY во время метода Bind () при настройке сетевого соединения. Это оставляет Windows самому принимать решение.
Выбор адреса в Windows 2008 и более поздних версиях основан на наибольшем количестве совпадающих бит со следующим переходом, что означает, что ответ зависит от вашего шлюза по умолчанию (или любых конкретных маршрутов, которые вы, возможно, определили).
Я не нашел упоминания о маршрутах или шлюзах на вашей диаграмме, так что это насколько я мог понять.
Удачи!