Tl; Dr

Mam instancję programu SQL Server (SQLSERVER01-i01) z dedykowanym adresem IP i portem (162.xxx.xxx.51: 1433) na SQL Server z wieloma instancjami (każda instancja SQL Server na Windows Server ma swój własny adres IP ), które działają na jednym serwerze Windows (SQLSERVER01 / 162.xxx.xxx.50).

Mam także dedykowaną instancję Reporting Services (SQLSERVERRS01-i01) z własnym adresem IP i portem (168.xxx.xxx.71: 1433), która działa na innym serwerze Windows (SQLSERVERRS01) z własnym adresem IP (168 .xxx.xxx.70).

Dedykowany serwer usług raportowania ma aplikację, do APPL1której można uzyskać dostęp za pośrednictwem http://SQLSERVERRS01-i01:80/Reports_APPL1lub za pośrednictwem http://SQLSERVERRS01:80/Reports_APPL1.

SSRS odbierze oba żądania z powodu *:80konfiguracji w Reporting Services Configuration dla nagłówków hosta.

Mamy wiele zapór ogniowych między każdym zakresem adresów IP, co oznacza, że ​​musimy złożyć wniosek o określoną regułę dla każdego połączenia IP-IP-IP lub IPrange-to-IP. Jednak gdy zaangażowane są dwa serwery, bezpieczeństwo nakazuje, aby zawsze była to reguła IP-to-IP w zaporze.

Pytanie

(na podstawie zrzutu ekranu poniżej)

Gdy serwer Reporting Services łączy się z wystąpieniem programu SQL Server (w wersji 162.xxx.xxx.51) w celu pobrania danych, czy zawsze nawiąże połączenie z podstawowym adresem IP serwera Windows (168.xxx.xxx.70 / preferowany ), na którym działa usługa SSRS, czy też (czasami) użyje adresu IP instancji SQL Server Reporting Services (168.xxx.xxx.71)?

Jest to istotne dla konfiguracji reguły zapory ogniowej przy użyciu podejścia IP-to-IP. Będę musiał wystąpić o regułę, która definiuje połączenie od 168.xxx.xxx.71 do 162.xxx.xxx.51 przez port 1433 lub od połączenia 168.xxx.xxx.70 do 162.xxx.xxx.51 poprzez port 1433.

Obecnie ubiegałbym się o obie reguły zapory ogniowej.

Pytanie bonusowe

Czy mogę skonfigurować serwer Reporting Services do komunikacji z dedykowanym adresem IP? W tym przypadku z adresem 168.xxx.xxx.71.

Odpowiedzi, których nie szukam

Nie szukam porady, jak zoptymalizować konfigurację zapory ogniowej ani jak wdrożyć koncepcję podziału na strefy dla naszych sieci. (Jest już w przygotowaniu). Ponadto nie jestem zainteresowany opiniami sugerującymi, że SQL Server i SSRS na tym samym serwerze rozwiązałyby moje problemy. Wiem o tym i chętnie bym to zrobił, gdyby nie oprogramowanie zewnętrzne wymagane do współpracy z komponentami SSRS.

To działa

Konfiguracja, którą mam działa, jeśli zastosuję obie reguły zapory między instancją SSRS i SQL Server.

168.xxx.xxx.71 --> 162.xxx.xxx.51 : 1433
168.xxx.xxx.70 --> 162.xxx.xxx.51 : 1433

Chcę bezpiecznie zmniejszyć jedną regułę zapory i zapewnić, że wszystko będzie nadal działać. (Zobacz zrzut ekranu poniżej)
Edycja: Artykuły, które przeczytałem do tej pory sugerują, że potrzebuję tylko drugiej reguły, ale nie ma gwarancji.

Artykuły, z którymi już się konsultowałem

1. Zagadnienia bezpieczeństwa dotyczące
   artykułu dotyczącego instalacji programu SQL Server .

2. Skonfiguruj Zaporę systemu Windows, aby umożliwić dostęp do programu SQL Server W
   tym artykule wskazano wszystkie inne artykuły dotyczące konfiguracji zapory dla programu SQL Server.

3. Skonfiguruj Zaporę systemu Windows dla dostępu do aparatu bazy danych
   Nie użyto słowa adresów IP.

4. Skonfiguruj zaporę dla dostępu do serwera raportów
   Ten artykuł był dość interesujący, jak zauważono:

   Jeśli uzyskujesz dostęp do relacyjnych baz danych SQL Server na komputerach zewnętrznych lub jeśli baza danych serwera raportów znajduje się w zewnętrznej instancji SQL Server, musisz otworzyć port 1433 i 1434 na komputerze zewnętrznym.

   ... ale wciąż nie ma słowa o konfiguracji / ustawieniach / domyślnych adresach IP.

5. Wybór źródłowego adresu IP na komputerze z systemem Windows Multi-Homed

6. Funkcje wyboru źródłowego adresu IP w systemie Windows Server 2008 i Windows Vista różnią się od odpowiednich funkcji we wcześniejszych wersjach systemu Windows

Artykuły 5 i 6 zostały mi łaskawie dostarczone przez Jamesa (dba.se). Obecnie wydają się być najbardziej odpowiednimi odpowiedziami. Jestem jednak nieco sceptyczny, że jeden artykuł wspomina o użyciu wielu kart sieciowych, podczas gdy mam tylko jedną kartę sieciową z wieloma adresami IP. Tom (dba.se) również zapoznał się z poradami i ogólnymi komentarzami.

Dlaczego tutaj, a nie w dba.stackexchange.com

Na początku byłem niechętny, aby opublikować to pytanie na serverfault.com z powodu złożonej natury pytania. Pytanie ma zarówno tendencję do specyficznego SQL Server, jak i Windows Server. W końcu zdecydowałem się opublikować go tutaj, ponieważ uważam, że jest to problem z obsługą adresów IP systemu Windows Server (z powodu utraty lepszych słów).

Jeśli moderator myśli, że otrzymam lepszą odpowiedź na stronie dba.stackexchange.com, przenieś pytanie tutaj.

Długie wyjaśnienie

W naszym środowisku mamy serwery Windows obsługujące wiele instancji SQL Server i wiele ustawień IP. Dodajemy złożone konfiguracje zapory, dedykowane serwery SQL Server Reporting Services (SSRS) i opracowujemy środowisko, które wygląda trochę tak:

Zasadniczo możemy mieć jeden system Windows Server z maksymalnie 15 (piętnastoma) wystąpieniami SQL Server na poszczególnych adresach IP. To samo dotyczy dedykowanej instancji Reporting Services.

Reguły zapory ogniowej

Różne zakresy adresów IP nie są obecnie skonfigurowane jako strefy, co oznacza, że ​​musimy skonfigurować każdą regułę zapory niezależnie jako regułę IP-na-IP lub IPrange-na-IP. Gdy zaangażowane są dwa serwery, bezpieczeństwo nakazuje, aby zawsze była to reguła IP do IP. Każda instancja SQL Server będzie miała swój własny zestaw reguł dla zapór ogniowych zaangażowanych w komunikację, czy to będzie połączenie serwer-serwer lub klient-serwer. Złożenie wniosku o regułę zapory wymaga obecnie od czterech do sześciu tygodni okresu oczekiwania. Zmniejszenie liczby reguł zapory ogniowej zmniejszy presję na zespół bezpieczeństwa sieci.

Konfiguracja IP wystąpienia programu SQL Server

Konfigurowanie instancji SQL Server do pobierania tylko na dedykowanym adresie IP i porcie jest wykonywane przez modyfikację niektórych ustawień w narzędziu SQL Server Configuration Manager. Pierwszym krokiem jest uruchomienie Menedżera konfiguracji SQL Server, aw lewej sekcji wybierz Konfiguracja sieci SQL Server | Protokoły dla InstanceName . W lewym okienku kliknij lewym przyciskiem myszy nazwę protokołu TCP / IP i włącz protokół. Następnie ponownie kliknij protokół lewym przyciskiem myszy i wyświetl okno Właściwości dla TCP / IP .

Następnie upewnij się, że następujące ustawienia są ustawione w rejestrze protokołu :

Enabled           : Yes
Listen All        : No

W rejestrze adresów IP sprawdź następujące ustawienia adresu IP, o którym mowa (np. Dla serwera Reporting Services w tym przykładzie byłoby to 168.xxx.xxx.71)

Active            : Yes
Enabled           : Yes
IP Address        : 168.xxx.xxx.71
TCP Dynamic Ports : 
TCP Port          : 1433

Uwaga: Ważne jest, aby ustawienie dla portów dynamicznych TCP było puste, a nie tylko 0 (zero).

Teraz masz instancję SQL Server, która będzie pobierać połączenia z bazą danych tylko na 168.xxx.xxx.71 przy użyciu portu 1433.

Podsumowanie wystąpienia programu SQL Server

Usługa przeglądarki SQL Server nie jest uruchomiona, a każda indywidualna instancja SQL Server jest skonfigurowana do używania tylko własnego adresu IP na porcie 1433. Biorąc pod uwagę instancję SQL Server o nazwie GENERAL, serwer Windows o nazwie hosta SQLSERVER01 i dwa adresy IP 162.xxx .xxx.50 (host) i 162.xxx.xxx.51 (instancja SQL) Skończę z następującymi elementami konfiguracji:

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 nie odbierze żądań 162.xxx.xxx.50: 1433, ponieważ żadna instancja SQL Server nie jest skonfigurowana do nasłuchiwania tego adresu IP w narzędziu SQL Server Configuration Manager. SQL Server będzie pobierał tylko żądania SQLSERVER01-i01 (na porcie 1433) lub 162.xxx.xxx.51,1433.

Podsumowanie wystąpienia usług SQL Server Reporting Services

Usługa przeglądarki SQL Server nie jest uruchomiona, a każda indywidualna instancja SQL Server Reporting Services jest skonfigurowana do używania tylko własnego adresu IP na porcie 1433. Biorąc pod uwagę instancję SQL Server Reporting Services o nazwie GENERAL, serwer Windows o nazwie hosta SQLSERVERRS01, aplikacja na nazwanych SSRS APPL1i dwóch adresach IP 168.xxx.xxx.70 (host) i 168.xxx.xxx.71 (instancja SQL) skończę z następującymi elementami konfiguracji:

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 nie odbierze żądań dla 168.xxx.xxx.70: 1433, ponieważ żadna instancja SQL Server nie jest skonfigurowana do nasłuchiwania tego adresu IP w narzędziu SQL Server Configuration Manager. SQL Server będzie pobierał tylko żądania SQLSERVER01-i01 (na porcie 1433) lub 162.xxx.xxx.71,1433.

Usługi SSRS będą odbierać żądania http: // sqlserverrs01-i01 / Reports_APPL1 lub http: // sqlserverrs01 / Reports_APPL1 z powodu konfiguracji *: 80 w konfiguracji usług raportowania dla nagłówków hosta.

Mam nadzieję, że dostarczyłem wystarczającą ilość informacji dla każdego, kto chciałby spędzić czas na pisaniu odpowiedzi i czekam na wasze dane techniczne i linki.

Napisane za pomocą StackEdit, a później ręcznie zmodyfikowane, aby były zgodne z wymianą stosów .

Historia

Edycja 1 : Pierwsza wersja
Edycja 2 : Przeformatowana pod kątem czytelności. Przeniesiono wyjaśnienie SF / DB w dół. Dodano nazwę hosta dla Windows Server
Edycja 3 : Naprawiono nieprawidłowe adresy IP na liście reguł zapory.
Edycja 4 : w niektórych miejscach zmieniono słowo hosting na uruchomione (jest to środowisko niezirtualizowane). Dodano adres IP w jednym zdaniu
Edytuj 5 : Dodano listę artykułów, z którymi się skonsultowałem i wspomniałem o wsparciu
Edytuj 6 : Sekcja Historia oczyszczonych

Wprowadzenie

Według różnych dokumentów, które znalazłem podczas moich pierwszych badań oraz dokumentów zawartych w linkach i dyskusjach, opracowałem solidne, niezawodne i zgodne rozwiązanie.

RFC 3484

Dalsze porównania binarne i zastosowane reguły są zgodne z RFC 3484, który najwyraźniej dotyczy również adresów IPv4.

RFC 3484 stwierdza również, że zaraz po Regule 8 to

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.

Wybór źródłowego adresu IP na komputerze z systemem Windows Multi-Homed

Teraz nie wszystkie reguły w RFC 3484 dotyczą adresów IPv4. Artykuł w blogu Microsoft Wybór źródła adresu IP na komputerze z systemem Windows z wieloma domami wyjaśnia, które zasady mają zastosowanie.

Tuż pod zachowaniem systemu Windows Vista / Windows Server 2008 znajduje się niewielka sekcja, która brzmi:

Podobnie jak XP, gdy program nie określa źródłowego adresu IP, stos odwołuje się do docelowego adresu IP, a następnie sprawdza całą tablicę tras IP, aby mógł wybrać najlepszą kartę sieciową, przez którą ma zostać wysłany pakiet. Po wybraniu karty sieciowej stos używa procesu wyboru adresu zdefiniowanego w RFC 3484 i używa tego adresu IP jako źródłowego adresu IP dla pakietów wychodzących.

Ponieważ mam tylko jedną kartę sieciową w instancji SQL / SSRS, pierwsza część jest dyskusyjna. Windows Server zawsze wybierze jedyną dostępną kartę sieciową.

Dotychczasowe połączenie RFC 3484 z blogiem Microsoft powoduje, że oba adresy IP są ważnymi kandydatami na źródłowy adres IP. Wyjaśnienie to znajduje się w dalszej części odpowiedzi.

The Cable Guy

Artykuł od Cable Guy The Cable Guy Strong and Weak Host Modele zawiera więcej szczegółów na temat działania wyboru IP w silnym środowisku wysyłania i odbierania hosta oraz w środowisku słabego hosta wysyłania i odbierania . Dobry dodatkowy odczyt, ale nie rzuca więcej światła na sposób wyboru źródłowego adresu IP. Artykuł dotyczy znanego już RFC 3484.

Wyjaśniając to, co niewytłumaczalne

Aby wyjaśnić rozwiązanie, musimy najpierw przekonwertować omawiane adresy IP na ich binarne odpowiedniki. Ponieważ w swoim pytaniu nie podałem bram, przyjmuję dwie wartości.

Źródłowe adresy IP i notacja binarna

Oto lista przekonwertowanych wartości binarnych dla zaangażowanych adresów 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

Docelowe adresy IP i notacja binarna

10101000.00000000.00000000.00110011   168.xxx.xxx.051/128   SQL Server

Przykład 1: Adres IP bramy niższy niż adres IP wystąpienia SQL / SSRS

W tym przykładzie założę, że adres IP bramy jest niższy niż adres IP wystąpienia SQL Server / SSRS, a mianowicie 168.001.001.002.

Jeśli porównasz oba adresy binarne instancji Windows Server i SQL Server / SSRS, masz następujące możliwości:

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)

Przykład wyniku 1

W tym przykładzie oba adresy IP mają tę samą liczbę pasujących bitów wysokiego rzędu (lub najdłuższy pasujący prefiks). Do tej pory proces http.sys używał jednego z adresów IP do komunikacji wychodzącej.

Przykład 2: Adres IP bramy wyższy niż adres IP wystąpienia SQL / SSRS

W tym przykładzie założę, że adres IP bramy jest wyższy niż adres IP wystąpienia SQL Server / SSRS, a mianowicie 168.001.001.100.

Jeśli porównasz oba adresy binarne instancji Windows Server i SQL Server / SSRS, masz następujące możliwości:

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)

Przykład wyniku 2

Mimo że adres IP bramy jest teraz wyższy niż adres IP serwera Windows i instancji SQL / SSRS, ilość pasujących bitów wysokiego rzędu (lub najdłuższego pasującego prefiksu) jest nadal taka sama. Do tej pory proces http.sys używał jednego z adresów IP do komunikacji wychodzącej.

Podsumowanie dotychczasowych ustaleń

Jak dotąd nie można powiedzieć, który adres IP będzie używany przez proces http.sys do komunikacji wychodzącej działającej w instancji SQL / SSRS (.71) na serwerze Windows (.70).

„Kiedy wyeliminowałeś niemożliwe, wszystko, co jest nieprawdopodobne, musi być prawdą” - Sherlock Holmes

Są sytuacje, w których źródłowy adres IP można zdecydowanie wskazać / wybrać / zdefiniować za pomocą wyżej wspomnianej wiedzy RFC i Microsoft. Ale jeśli adresy IP są zbyt blisko siebie i w pobliżu bramy, to wszystko zależy od szczęścia. Albo to jest?

Widząc, że jestem w stanie tworzyć reguły (zapory), a Microsoft ma ...

implementacja (to) ma inne możliwości wyboru spośród adresów źródłowych. Na przykład, jeśli implementacja w jakiś sposób wie, który adres źródłowy spowoduje „najlepszą” wydajność komunikacji.

... to wszystko, co muszę zrobić, aby określić adres IP procesu http.sys, to utworzyć tylko jedną regułę zapory z żądanym adresem IP.

Co się dzieje

1. Definiuję regułę zapory od 168.xxx.xxx.71 do 168.xxx.xxx.51: 1433
2. Składnik http.sys instancji SQL / SSRS jest zgodny z RFC 3484 i wybiera źródłowy adres IP zgodnie ze zdefiniowanymi regułami
3. Adres IP 168.xxx.xxx.71 (na karcie NIC1) jest określany jako źródłowy adres IP do osiągnięcia adresu IP 168.xxx.xxx.51 przez port 1433, a zatem jest przypisywany do wszystkich wychodzących pakietów

Korzyści

1. W żaden sposób nie ingeruję w implementację RFC 3484
2. W żaden sposób nie żongluję trasami ani konfiguracjami ARP
3. Jestem zgodny z RFC 3484 i implementacją Microsoftu
4. Nie włamuję się do żadnych ustawień rejestru ani konfiguracji systemu
5. MNIEJ JEDEN ZASADA POŻARU

Weryfikacja

Muszę jeszcze usunąć adres IP z reguł zapory, ale jestem pewien, że będzie działał zgodnie z przeznaczeniem / definicją. Podsumowanie nastąpi.

Historia

Edytuj 1 Początkowy post
Edytuj 2 Wyczyść odpowiedź, dodano sekcję Historia

SSRS obsługuje kilka standardowych źródeł danych, a także inne źródła danych .NET:

https://msdn.microsoft.com/en-ca/library/ms159219.aspx

Zakładając, że używasz rodzimego klienta SQL dla źródła danych, nie masz możliwości podania źródłowego adresu IP:

https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring(v=vs.110).aspx

Dlatego jest oczywiste, że klient użyje IPADDR_ANY podczas metody Bind () podczas konfigurowania połączenia sieciowego. To pozostawia Windowsowi podjęcie decyzji.

Wybór adresu w systemie Windows 2008 i nowszych opiera się na największej liczbie pasujących bitów z następnym przeskokiem, co oznacza, że ​​odpowiedź zależy od domyślnej bramy (lub dowolnych określonych tras, które zdefiniowałeś).

https://blogs.technet.microsoft.com/networking/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer/

Nie widziałem żadnej wzmianki o trasach ani bramach na twoim diagramie, więc to tak daleko, jak tylko mogłem.

Powodzenia!