Обработка 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 Reporting Services (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-адресах не используются.Настройка брандмауэра для доступа к серверу отчетов
Эта статья была довольно интересной, поскольку в ней было отмечено:Если вы обращаетесь к реляционным базам данных 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. 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 : Убран раздел истории
SSRS поддерживает несколько стандартных источников данных, а также другие источники данных .NET:
https://msdn.microsoft.com/en-ca/library/ms159219.aspx
Предполагая, что вы используете собственный SQL клиент для источника данных, у вас нет возможности указать исходный IP-адрес:
Следовательно, очевидно, что клиент будет использовать IPADDR_ANY во время метода Bind () при настройке сетевого соединения. Это оставляет Windows самому принимать решение.
Выбор адреса в Windows 2008 и выше основан на наибольшем количестве совпадающих битов со следующим переходом, что означает, что ответ зависит от вашего шлюза по умолчанию (или любых конкретных маршрутов, которые вы, возможно, определили).
Я не видел любое упоминание маршрутов или шлюзов на вашей диаграмме, так что это насколько я смог понять.
Удачи!
Введение
Согласно различным документам, которые я нашел во время моего первоначального исследования, а также документам, предоставленным в ссылках и обсуждениях, я пришел к прочному, надежному и совместимому решению.
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.
Source Выбор 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-адрес. Объяснение следует далее в ответе.
The Cable Guy
Статья из Cable Guy Cable Guy Strong and Weak Host Models дает более подробную информацию о том, как выбор 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 Исправлен ответ, добавлен раздел истории