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 : Раздел «Очистить историю»
источник
Ответы:
Введение
В соответствии с различными документами, которые я нашел во время моего первоначального исследования, и документами, представленными в ссылках и обсуждениях, я нашел твердое, надежное и совместимое решение.
RFC 3484
Двоичные сравнения проводятся далее, и применяемые правила соответствуют RFC 3484, который, очевидно, также действителен для адресов IPv4.
RFC 3484 также утверждает сразу после правила 8, что
Выбор исходного IP-адреса на многосетевом компьютере Windows
Теперь не все правила в RFC 3484 применяются к адресам IPv4. Статья в блоге Microsoft Выбор исходного IP-адреса на многосетевом компьютере Windows объясняет, какие правила применяются.
Прямо под поведением Windows Vista / Windows Server 2008 есть небольшой раздел, который гласит:
Видя, как у меня есть только один сетевой адаптер в SQL / SSRS экземпляр первой части является спорным. Windows Server всегда выбирает единственный доступный сетевой адаптер.
Пока что объединение RFC 3484 с блогом Microsoft приводит к тому, что оба IP-адреса являются подходящими кандидатами на исходный IP-адрес. Объяснение следует далее в ответе.
Кабельщик
Статья от Cable Guy Модели сильного и слабого хоста Cable Guy более подробно рассказывают о том, как работает выбор IP в среде отправки и получения сильного хоста и в среде отправки и получения слабого хоста . Хорошее дополнительное чтение, но не проливает свет на то, как выбран исходный IP. Статья относится к уже известной RFC 3484.
Объясняя необъяснимое
Чтобы объяснить решение, мы сначала должны преобразовать рассматриваемые IP-адреса в их двоичные эквиваленты. Поскольку в моем вопросе я не указал шлюзы, я приму два значения.
Исходные IP-адреса и двоичные обозначения
Вот список преобразованных двоичных значений для задействованных IP-адресов.
Целевые IP-адреса и двоичные обозначения
Пример 1: IP-адрес шлюза ниже, чем IP-адрес SQL / SSRS
В этом примере я собираюсь предположить, что IP-адрес шлюза ниже, чем IP-адрес экземпляра SQL Server / SSRS, а именно 168.001.001.002.
Если вы сравните оба двоичных адреса экземпляра Windows Server и SQL Server / SSRS, то у вас будет следующее:
Результат Пример 1
В этом примере оба IP-адреса имеют одинаковое количество совпадающих старших битов (или самый длинный совпадающий префикс). До сих пор процесс http.sys будет использовать любой из IP-адресов для исходящих сообщений.
Пример 2: IP-адрес шлюза выше, чем IP-адрес экземпляра SQL / SSRS
В этом примере я собираюсь предположить, что IP-адрес шлюза выше, чем IP-адрес экземпляра SQL Server / SSRS, а именно 168.001.001.100.
Если вы сравните оба двоичных адреса экземпляра Windows Server и SQL Server / SSRS, то у вас будет следующее:
Результат примера 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-адресом.
Что просходит
Льготы
верификация
Мне еще предстоит удалить IP-адрес из правил брандмауэра, но я уверен, что он будет работать так, как задумано / определено. Резюме будет следовать.
история
Редактировать 1 Начальное сообщение
Редактировать 2 Убран ответ, добавлен раздел История
источник
SSRS поддерживает несколько стандартных источников данных, а также другие источники данных .NET:
https://msdn.microsoft.com/en-ca/library/ms159219.aspx
Предполагая, что вы используете собственный клиент SQL для источника данных, у вас нет возможности указать IP-адрес источника:
https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring(v=vs.110).aspx
Поэтому вполне понятно, что клиент будет использовать IPADDR_ANY во время метода Bind () при настройке сетевого подключения. Это оставляет Windows, чтобы принять решение.
Выбор адреса в Windows 2008 и выше основан на наибольшем количестве совпадающих битов со следующим переходом, что означает, что ответ зависит от вашего шлюза по умолчанию (или любых других определенных вами маршрутов).
https://blogs.technet.microsoft.com/networking/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer/
Я не видел никаких упоминаний о маршрутах или шлюзах на вашей диаграмме, так что это насколько я мог получить.
Удачи!
источник