Tl; д-р

У мене є екземпляр SQL Server (SQLSERVER01-i01) з виділеною IP-адресою та портом (162.xxx.xxx.51: 1433) на багатоекземплярному SQL сервері (у кожного екземпляра SQL Server на Windows Server є своя IP-адреса ), які працюють на одному сервері Windows (SQLSERVER01 / 162.xxx.xxx.50).

У мене також є виділений екземпляр Служб звітування (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конфігурацію в Конфігурації служб звітування для заголовків хоста.

У нас є кілька брандмауерів між кожним діапазоном IP, а це означає, що ми маємо подати певне правило для кожного з'єднання IP-IP або IPrange-IP-з'єднання. Однак, коли задіяні два сервери, тоді безпека диктує, що у брандмауері завжди повинно бути правило IP-IP.

Питання

(на основі екрана, знятого далі)

Коли сервер Служб звітування підключиться до екземпляра 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

Я хочу безпечно скоротити одним правилом брандмауера і гарантувати, що все ще працюватиме. (Див. Знімок екрана далі)
Редагувати: статті, які я читав до цього часу, передбачають, що мені потрібно лише друге правило, але гарантії немає.

Статті я вже консультував

1. Міркування щодо безпеки
   статті статті інсталяції SQL Server .

2. Налаштуйте Брандмауер Windows для дозволу доступу до SQL Server
   Ця стаття вказує на всі інші статті щодо конфігурації брандмауера для SQL Server.

3. Налаштування брандмауера Windows для доступу до бази даних двигуна
   Не використовується жодне слово IP-адреси.

4. Налаштування брандмауера для доступу до сервера звітів
   Ця стаття була досить цікавою, як зазначалося:

   Якщо ви отримуєте доступ до реляційних баз даних SQL Server на зовнішніх комп'ютерах або якщо база даних серверів звітів знаходиться на зовнішньому екземплярі SQL Server, ви повинні відкрити порти 1433 та 1434 на зовнішньому комп'ютері.

   ... але все ще не йдеться про налаштування / налаштування / за замовчуванням IP-адреси.

5. Вибір вихідної IP-адреси на комп’ютері з декількома ходами Windows

6. Функціонал для вибору вихідної IP-адреси в Windows Server 2008 та в Windows Vista відрізняється від відповідної функціональності в попередніх версіях Windows

Статті 5 та 6 були мені люб'язно надані Джеймсом (dba.se). В даний час вони здаються найбільш підходящими відповідями. Однак я трохи скептично налаштований на те, що в одній статті згадується використання декількох НІК, тоді як у мене є лише один НІК з декількома IP-адресами, призначеними для нього. Том (dba.se) також скористався порадами та загальними коментарями.

Чому тут, а не на dba.stackexchange.com

Спочатку я неохоче розміщував це питання на сервері defaultfault.com через складний характер питання. Питання має обидві тенденції бути специфічними для SQL Server, а також бути специфічними для Windows Server. Врешті-решт я вирішив опублікувати його тут, бо вважаю, що це обробка IP-адрес Windows Server (для втрати кращих слів).

Якщо модератор думає, що я отримаю кращу відповідь на dba.stackexchange.com, тоді, будь ласка, перенесіть питання туди.

Довге пояснення

У нашому середовищі у нас є сервери Windows, на яких розміщено кілька екземплярів SQL Server та декілька параметрів IP. Ми додаємо складні конфігурації брандмауера, виділені сервери звітів SQL Server (SSRS) і створюємо середовище, яке виглядає приблизно так:

В основному у нас може бути один сервер Windows, який працює до 15 (п'ятнадцяти) екземплярів SQL Server на окремих IP-адресах. Те саме стосується спеціалізованого екземпляра Служб звітування.

Правила брандмауера

Наразі різні діапазони IP не конфігуруються як зони, а це означає, що ми маємо самостійно налаштовувати кожне правило брандмауера як правило IP-to-IP або IPrange-to-IP. Коли задіяні два сервери, тоді безпека диктує, що це завжди має бути правилом IP-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-адрес перевірте наступні параметри відповідної 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 Configuration Manager. 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 у Конфігурації служб звітування для заголовків хоста.

Я сподіваюся, що я надав достатньо інформації для всіх, хто бажає витратити свій час на написання відповіді, і я з нетерпінням чекаю ваших технічних деталей та посилань.

Написано за допомогою StackEdit і пізніше зміниться вручну, щоб бути сумісним з stackexchange.

Історія

Редагувати 1 : Початковий випуск
Редагувати 2 : Переформатований для читабельності. Пояснення переміщено SF / DB вниз. Додано ім'я хоста для Windows Server
Edit 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. Стаття в блозі Майкрософт Вибір джерела IP-адреси на комп’ютері з багатопотужними Windows пояснює, які правила застосовуються.

Існує невеликий розділ трохи нижче Поведінка Windows Vista / Windows Server 2008, який говорить:

Подібно до XP, коли програма не вказує вихідний IP-код, стек посилається на цільову IP-адресу, а потім вивчає всю таблицю маршруту IP, щоб вона могла вибрати найкращий мережевий адаптер, над яким відправити пакет. Після вибору мережного адаптера стек використовує процес вибору адреси, визначений в RFC 3484, і використовує цю IP-адресу як вихідну IP-адресу для вихідних пакетів.

Бачачи, як у мене є лише один NIC в екземплярі SQL / SSRS, перша частина є спірною. Windows Server завжди обирає єдиний доступний NIC.

Поки поєднання RFC 3484 з Microsoft Blog призводить до того, що обидва IP-адреси є дійсними кандидатами на вихідну IP-адресу. Пояснення далі йде у відповіді.

Кабельний хлопець

У статті із кабельного хлопця Моделі кабельного хлопця сильні та слабкі хости розглядаються детальніше про те, як працює вибір 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-адресою.

Що сталося

1. Я визначаю правило брандмауера від 168.xxx.xxx.71 до 168.xxx.xxx.51: 1433
2. Компонент http.sys екземпляра SQL / SSRS відповідає RFC 3484 і вибирає вихідний IP відповідно до визначених правил
3. IP-адреса 168.xxx.xxx.71 (на NIC1) визначається як вихідна IP-адреса для досягнення IP-адреси 168.xxx.xxx.51 через порт 1433 і, таким чином, призначається всім вихідним пакетам

Переваги

1. Я жодним чином не перешкоджаю реалізації RFC 3484
2. Я жодним чином не жонглюю маршрутами чи конфігураціями ARP
3. Я відповідаю RFC 3484 та впровадженню Microsoft
4. Я не зламаю жодних параметрів реєстру чи конфігурацій системи
5. Я маю ОДНЕ ПОЖАРОВЕ ПРАВИЛА менше

Перевірка

Мені ще не видалено 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/

Я не бачив у вашій діаграмі жодної згадки про маршрути чи шлюзи, так що я міг би дістатись.

Удачі!