Tl; Dr.

Ich habe eine SQL Server-Instanz (SQLSERVER01-i01) mit einer dedizierten IP-Adresse und einem dedizierten Port (162.xxx.xxx.51: 1433) auf einem SQL Server mit mehreren Instanzen (jede SQL Server-Instanz auf dem Windows Server hat ihre eigene IP-Adresse ), die alle auf einem Windows-Server ausgeführt werden (SQLSERVER01 / 162.xxx.xxx.50).

Ich habe auch eine dedizierte Reporting Services-Instanz (SQLSERVERRS01-i01) mit einer eigenen IP-Adresse und einem eigenen Port (168.xxx.xxx.71: 1433), die auf einem anderen Windows-Server (SQLSERVERRS01) mit einer eigenen IP-Adresse (168) ausgeführt wird .xxx.xxx.70).

Der dedizierte Reporting Services-Server verfügt über eine Anwendung, APPL1die entweder über http://SQLSERVERRS01-i01:80/Reports_APPL1oder über erreichbar ist http://SQLSERVERRS01:80/Reports_APPL1.

SSRS nimmt beide Anforderungen aufgrund der *:80Konfiguration in der Reporting Services-Konfiguration für die Host-Header auf.

Wir haben mehrere Firewalls zwischen jedem IP-Bereich, was bedeutet, dass wir für jede IP-zu-IP- oder IP-Bereich-zu-IP-Verbindung eine bestimmte Regel anwenden müssen. Wenn jedoch zwei Server beteiligt sind, schreibt die Sicherheit vor, dass es sich immer um eine IP-zu-IP-Regel in der Firewall handeln muss.

Frage

(basierend auf dem Screenshot weiter unten)

Wenn der Reporting Services-Server eine Verbindung zur SQL Server-Instanz (unter 162.xxx.xxx.51) herstellt, um Daten abzurufen, wird immer eine Verbindung mit der zugrunde liegenden IP-Adresse des Windows-Servers hergestellt (168.xxx.xxx.70 / bevorzugt) ) auf dem SSRS ausgeführt wird, oder wird (manchmal) die IP-Adresse der SQL Server Reporting Services-Instanz (168.xxx.xxx.71) verwendet?

Dies ist relevant für die Konfiguration der Firewall-Regel mithilfe eines IP-zu-IP-Ansatzes. Ich muss entweder eine Regel beantragen, die eine Verbindung von 168.xxx.xxx.71 bis 162.xxx.xxx.51 über Port 1433 oder eine Verbindung von 168.xxx.xxx.70 bis 162.xxx.xxx.51 über definiert Port 1433.

Derzeit würde ich beide Firewall-Regeln beantragen.

Bonus-Frage

Kann ich den Reporting Services-Server für die Kommunikation mit einer dedizierten IP-Adresse konfigurieren? In diesem Fall mit der Adresse 168.xxx.xxx.71.

Antworten, die ich nicht suche

Ich suche keinen Rat, wie die Firewall-Konfiguration optimiert oder ein Zoning-Konzept für unsere Netzwerke implementiert werden kann. (Es ist bereits in der Pipeline). Außerdem bin ich nicht an Rückmeldungen interessiert, die darauf hindeuten, dass SQL Server und SSRS auf demselben Server meine Probleme lösen würden. Ich weiß das und würde es gerne tun, außer für die Software von Drittanbietern, die zusammen mit den SSRS-Komponenten ausgeführt werden muss.

Es klappt

Die Konfiguration, die ich habe, funktioniert, wenn ich beide Firewall-Regeln zwischen der SSRS- und der SQL Server-Instanz anwende.

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

Ich möchte sicher um eine Firewall-Regel reduzieren und sicherstellen, dass alles noch funktioniert. (Siehe Screenshot weiter unten)
Bearbeiten: Die Artikel, die ich bisher gelesen habe, deuten darauf hin, dass ich nur die zweite Regel benötige, aber es gibt keine Garantie.

Artikel, die ich bereits konsultiert habe

1. Sicherheitsüberlegungen für einen
   Artikel zur SQL Server-Installationsbasis .

2. Konfigurieren der Windows-Firewall für den Zugriff auf SQL Server
   Dieser Artikel verweist auf alle anderen Artikel zur Firewall-Konfiguration für SQL Server.

3. Konfigurieren einer Windows-Firewall für den Zugriff auf das Datenbankmodul
   Kein Wort der verwendeten IP-Adressen.

4. Konfigurieren einer Firewall für den Berichtsserverzugriff
   Dieser Artikel war ziemlich interessant, da er Folgendes feststellte:

   Wenn Sie auf relationalen SQL Server-Datenbanken auf externen Computern zugreifen oder wenn sich die Berichtsserver-Datenbank auf einer externen SQL Server-Instanz befindet, müssen Sie die Ports 1433 und 1434 auf dem externen Computer öffnen.

   ... aber immer noch kein Wort über IP-Konfiguration / Einstellungen / Standardeinstellungen.

5. Auswahl der Quell-IP-Adresse auf einem Multi-Homed-Windows-Computer

6. Die Funktionalität zur Auswahl der Quell-IP-Adresse in Windows Server 2008 und in Windows Vista unterscheidet sich von der entsprechenden Funktionalität in früheren Windows-Versionen

Die Artikel 5 und 6 wurden mir freundlicherweise von James (dba.se) zur Verfügung gestellt. Sie scheinen derzeit die am besten geeigneten Antworten zu sein. Ich bin jedoch etwas skeptisch, dass in einem Artikel die Verwendung mehrerer Netzwerkkarten erwähnt wird, während mir nur eine Netzwerkkarte mit mehreren IPs zugewiesen ist. Tom (dba.se) hat sich ebenfalls mit Ratschlägen und allgemeinen Kommentaren eingemischt.

Warum hier und nicht in dba.stackexchange.com

Aufgrund der Komplexität der Frage zögerte ich zunächst, diese Frage auf serverfault.com zu stellen. Die Frage hat beide Tendenzen, SQL Server-spezifisch zu sein, aber auch Windows Server-spezifisch. Schließlich habe ich beschlossen, es hier zu posten, weil ich denke, dass es sich um ein Windows Server-IP-Handling handelt (wegen des Verlusts besserer Wörter).

Wenn ein Moderator der Meinung ist, dass ich in dba.stackexchange.com eine bessere Antwort erhalten werde, verschieben Sie die Frage bitte dorthin.

Die lange Erklärung

In unserer Umgebung haben wir Windows-Server, auf denen mehrere SQL Server-Instanzen und mehrere IP-Einstellungen gehostet werden. Wir fügen komplexe Firewall-Konfigurationen, dedizierte SSRS-Server (SQL Server Reporting Services) hinzu und entwickeln eine Umgebung, die ungefähr so ​​aussieht:

Grundsätzlich kann ein Windows Server bis zu 15 (fünfzehn) SQL Server-Instanzen auf einzelnen IP-Adressen ausführen. Gleiches gilt für die dedizierte Reporting Services-Instanz.

Firewall-Regeln

Die verschiedenen IP-Bereiche sind derzeit nicht als Zonen konfiguriert. Daher müssen wir jede Firewall-Regel unabhängig als IP-zu-IP- oder IP-Bereich-zu-IP-Regel konfigurieren. Wenn zwei Server beteiligt sind, schreibt die Sicherheit vor, dass es sich immer um eine IP-zu-IP-Regel handeln muss. Jede SQL Server-Instanz verfügt über eigene Regeln für die an der Kommunikation beteiligten Firewalls, sei es eine Server-zu-Server- oder eine Client-zu-Server-Verbindung. Die Beantragung einer Firewall-Regel führt derzeit zu einer Wartezeit von vier bis sechs Wochen. Durch die Reduzierung der Anzahl der Firewall-Regeln wird der Druck auf das Netzwerksicherheitsteam verringert.

IP-Konfiguration der SQL Server-Instanz

Das Konfigurieren einer SQL Server-Instanz so, dass sie nur von einer dedizierten IP und einem dedizierten Port abgerufen wird, erfolgt durch Ändern einiger Einstellungen im Dienstprogramm SQL Server Configuration Manager. Der erste Schritt besteht darin, den SQL Server-Konfigurationsmanager zu starten und im linken Abschnitt die SQL Server-Netzwerkkonfiguration | auszuwählen Protokolle für InstanceName . Klicken Sie im linken Bereich mit der linken Maustaste auf den TCP / IP- Protokollnamen und aktivieren Sie das Protokoll. Klicken Sie dann erneut mit der linken Maustaste auf das Protokoll und rufen Sie das Fenster Eigenschaften für TCP / IP auf.

Stellen Sie dann sicher, dass die folgenden Einstellungen im Protokollregister festgelegt sind:

Enabled           : Yes
Listen All        : No

In den IP - Adressen zu registrieren , für die IP - Adresse in Frage (zB für den Reporting Services - Server in diesem Beispiel für 168.xxx.xxx.71 wäre) die folgenden Einstellungen überprüfen

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

Hinweis: Es ist wichtig, dass die Einstellung für dynamische TCP-Ports leer ist und nicht nur eine 0 (Null).

Jetzt haben Sie eine SQL Server-Instanz, die nur Datenbankverbindungen auf 168.xxx.xxx.71 über den Port 1433 aufnimmt.

Zusammenfassung der SQL Server-Instanzen

Der SQL Server-Browserdienst wird nicht ausgeführt und jede einzelne SQL Server-Instanz ist so konfiguriert, dass nur ihre eigene IP-Adresse an Port 1433 verwendet wird. Bei einer SQL Server-Instanz namens GENERAL ein Windows-Server mit dem Hostnamen SQLSERVER01 und zwei IP-Adressen 162.xxx .xxx.50 (Host) und 162.xxx.xxx.51 (SQL-Instanz) Ich werde am Ende die folgenden Konfigurationselemente haben:

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

Der SQL Server empfängt keine Anforderungen für 162.xxx.xxx.50: 1433, da keine SQL Server-Instanz so konfiguriert ist, dass sie diese IP-Adresse im Dienstprogramm SQL Server Configuration Manager überwacht. Der SQL Server nimmt nur Anforderungen für SQLSERVER01-i01 (an Port 1433) oder 162.xxx.xxx.51,1433 entgegen.

Zusammenfassung der SQL Server Reporting Services-Instanzen

Der SQL Server-Browserdienst wird nicht ausgeführt und jede einzelne SQL Server Reporting Services-Instanz ist so konfiguriert, dass nur ihre eigene IP-Adresse an Port 1433 verwendet wird. Bei einer SQL Server Reporting Services-Instanz namens GENERAL handelt es sich um einen Windows-Server mit dem Hostnamen SQLSERVERRS01, einer Anwendung Auf dem benannten SSRS APPL1und zwei IP-Adressen 168.xxx.xxx.70 (Host) und 168.xxx.xxx.71 (SQL-Instanz) werden die folgenden Konfigurationselemente angezeigt:

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

Der SQL Server empfängt keine Anforderungen für 168.xxx.xxx.70: 1433, da keine SQL Server-Instanz so konfiguriert ist, dass sie diese IP-Adresse im Dienstprogramm SQL Server Configuration Manager überwacht. Der SQL Server nimmt nur Anforderungen für SQLSERVER01-i01 (an Port 1433) oder 162.xxx.xxx.71,1433 entgegen.

SSRS nimmt aufgrund der Konfiguration *: 80 in der Reporting Services-Konfiguration für die Host-Header Anforderungen für http: // sqlserverrs01-i01 / Reports_APPL1 oder http: // sqlserverrs01 / Reports_APPL1 auf .

Ich hoffe, ich habe genug Informationen für alle bereitgestellt, die bereit sind, ihre Zeit damit zu verbringen, eine Antwort zu schreiben, und freue mich auf Ihre technischen Details und Links.

Mit StackEdit geschrieben und später manuell geändert, um StackEchange-kompatibel zu sein.

Geschichte

Edit 1 : Erstveröffentlichung
Edit 2 : Zur besseren Lesbarkeit neu formatiert. Erklärung SF / DB nach unten verschoben. Hostname für Windows Server
Edit 3 hinzugefügt : Falsche IP-Adressen in der Liste der Firewall-Regeln behoben.
Bearbeiten 4 : Das Wort Hosting wurde an einigen Stellen in "Laufen" geändert (es ist eine nicht virtualisierte Umgebung). IP-Adresse in einmaligem Satz hinzugefügt
Bearbeiten 5 : Es wurde eine Liste von Artikeln hinzugefügt, die ich bereits konsultiert habe, und auf Support verwiesen.
Bearbeiten 6 : Bereinigter Verlauf

Einführung

Aufgrund der verschiedenen Dokumente, die ich bei meinen ersten Recherchen gefunden habe, und der Dokumente, die in Links und Diskussionen bereitgestellt wurden, habe ich eine solide, zuverlässige und konforme Lösung gefunden.

RFC 3484

Die weiter unten durchgeführten binären Vergleiche und die angewendeten Regeln entsprechen RFC 3484, der anscheinend auch für IPv4-Adressen gilt.

RFC 3484 besagt auch unmittelbar nach Regel 8, dass

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.

Auswahl der Quell-IP-Adresse auf einem Multi-Homed-Windows-Computer

Jetzt gelten nicht alle Regeln im RFC 3484 für IPv4-Adressen. Im Microsoft Blog-Artikel Auswahl der Quell-IP-Adresse auf einem Multi-Homed-Windows-Computer wird erläutert, welche Regeln gelten.

Es gibt einen kleinen Abschnitt direkt unter dem Verhalten von Windows Vista / Windows Server 2008 , der lautet:

Ähnlich wie bei XP verweist der Stack, wenn ein Programm keine Quell-IP angibt, auf die Ziel-IP-Adresse und überprüft dann die gesamte IP-Routentabelle, um den besten Netzwerkadapter auszuwählen, über den das Paket gesendet werden soll. Nachdem der Netzwerkadapter ausgewählt wurde, verwendet der Stapel den in RFC 3484 definierten Adressauswahlprozess und verwendet diese IP-Adresse als Quell-IP-Adresse für die ausgehenden Pakete.

Da ich nur eine Netzwerkkarte in der SQL / SSRS-Instanz habe, ist der erste Teil umstritten. Windows Server wählt immer die einzige verfügbare Netzwerkkarte aus.

Bisher führt die Kombination von RFC 3484 mit dem Microsoft-Blog dazu, dass beide IP-Adressen gültige Kandidaten für die Quell-IP-Adresse sind. Die Erklärung folgt weiter unten in der Antwort.

Der Kabel-Typ

In einem Artikel des Cable Guy Die Modelle für starke und schwache Hosts von Cable Guy erfahren Sie mehr darüber, wie die IP-Auswahl in einer Umgebung zum Senden und Empfangen von starken Hosts und in einer Umgebung zum Senden und Empfangen von schwachen Hosts funktioniert . Ein guter zusätzlicher Lesevorgang, der jedoch kein Licht mehr auf die Auswahl der Quell-IP wirft. Der Artikel bezieht sich auf den bereits bekannten RFC 3484.

Das Unerklärliche erklären

Um die Lösung zu erklären, müssen wir zuerst die fraglichen IP-Adressen in ihre binären Äquivalente konvertieren. Da ich in meiner Frage keine Gateways angegeben habe, gehe ich von zwei Werten aus.

Quell-IP-Adressen und Binärnotation

Hier ist eine Liste der konvertierten Binärwerte für die beteiligten IP-Adressen.

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

Ziel-IP-Adressen und Binärnotation

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

Beispiel 1: Gateway-IP niedriger als SQL / SSRS-Instanz-IP

In diesem Beispiel gehe ich davon aus, dass die IP-Adresse des Gateways niedriger ist als die IP-Adresse der SQL Server / SSRS-Instanz, nämlich 168.001.001.002.

Wenn Sie beide Binäradressen der Windows Server- und der SQL Server / SSRS-Instanz vergleichen, haben Sie Folgendes:

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)

Ergebnis Beispiel 1

In diesem Beispiel haben beide IP-Adressen die gleiche Anzahl übereinstimmender höherwertiger Bits (oder das längste übereinstimmende Präfix). Bisher verwendet der http.sys-Prozess eine der IP-Adressen für die ausgehende Kommunikation.

Beispiel 2: Gateway-IP höher als SQL / SSRS-Instanz-IP

In diesem Beispiel gehe ich davon aus, dass die IP-Adresse des Gateways höher ist als die IP-Adresse der SQL Server / SSRS-Instanz, nämlich 168.001.001.100.

Wenn Sie beide Binäradressen der Windows Server- und der SQL Server / SSRS-Instanz vergleichen, haben Sie Folgendes:

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)

Ergebnis Beispiel 2

Obwohl die IP-Adresse des Gateways jetzt höher ist als die IP-Adresse des Windows-Servers und der SQL / SSRS-Instanz, ist die Anzahl der übereinstimmenden höherwertigen Bits (oder des längsten übereinstimmenden Präfix) immer noch dieselbe. Bisher verwendet der http.sys-Prozess eine der IP-Adressen für die ausgehende Kommunikation.

Zusammenfassung der bisherigen Ergebnisse

Bisher ist es unmöglich zu sagen, welche IP-Adresse der http.sys-Prozess für ausgehende Kommunikationen verwendet, die auf der SQL / SSRS-Instanz (.71) auf dem Windows-Server (.70) ausgeführt werden.

"Wenn Sie das Unmögliche beseitigt haben, muss alles, was noch so unwahrscheinlich ist, die Wahrheit sein" - Sherlock Holmes

Es gibt Situationen, in denen die Quell-IP-Adresse mit den oben genannten RFC- und Microsoft-Kenntnissen definitiv genau festgelegt / ausgewählt / definiert werden kann. Aber wenn die IP-Adressen einfach zu nahe beieinander und in der Nähe des Gateways liegen, ist alles nur ein Zufall. Oder ist es?

Da ich in der Lage bin, die (Firewall-) Regeln zu erstellen, hat Microsoft eine ...

Die Implementierung (das) hat andere Möglichkeiten, zwischen Quelladressen zu wählen. Wenn die Implementierung beispielsweise irgendwie weiß, welche Quelladresse zu der "besten" Kommunikationsleistung führt.

... dann muss ich nur noch eine Firewall-Regel mit der gewünschten IP-Adresse erstellen , um die IP-Adresse des http.sys-Prozesses zu ermitteln .

Was geschieht

1. Ich definiere eine Firewall-Regel von 168.xxx.xxx.71 bis 168.xxx.xxx.51: 1433
2. Die http.sys-Komponente der SQL / SSRS-Instanz entspricht RFC 3484 und wählt die Quell-IP gemäß den definierten Regeln aus
3. Die IP-Adresse 168.xxx.xxx.71 (auf NIC1) wird als Quell-IP-Adresse bestimmt, um die IP-Adresse 168.xxx.xxx.51 über Port 1433 zu erreichen, und wird somit allen ausgehenden Paketen zugewiesen

Leistungen

1. Ich störe in keiner Weise in die Implementierung von RFC 3484
2. Ich jongliere in keiner Weise mit Routen oder ARP-Konfigurationen
3. Ich bin mit RFC 3484 und der Implementierung von Microsoft einverstanden
4. Ich hacke keine Registrierungseinstellungen oder Systemkonfigurationen
5. Ich habe eine Feuerwandregel weniger

Nachprüfung

Ich habe die IP-Adresse noch nicht aus den Firewall-Regeln entfernt, bin jedoch zuversichtlich, dass sie wie geplant / definiert funktioniert. Eine Zusammenfassung folgt.

Geschichte

Bearbeiten 1 Erster Beitrag
Bearbeiten 2 Bereinigte Antwort, Abschnitt "Verlauf" hinzugefügt

SSRS unterstützt mehrere Standarddatenquellen sowie andere .NET-Datenquellen:

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

Angenommen, Sie verwenden den nativen SQL-Client für die Datenquelle, haben Sie keine Möglichkeit, eine Quell-IP-Adresse anzugeben:

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

Daher liegt es nahe, dass der Client beim Einrichten der Netzwerkverbindung IPADDR_ANY während der Bind () -Methode verwendet. Dies lässt Windows die Entscheidung treffen.

Die Adressauswahl für Windows 2008 und höher basiert auf der höchsten Anzahl übereinstimmender Bits mit dem nächsten Hop. Dies bedeutet, dass die Antwort von Ihrem Standard-Gateway (oder den von Ihnen definierten spezifischen Routen) abhängt.

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

Ich habe in Ihrem Diagramm keine Erwähnung von Routen oder Gateways gesehen, so weit ich konnte.

Viel Glück!