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, APPL1
die entweder über http://SQLSERVERRS01-i01:80/Reports_APPL1
oder über erreichbar ist http://SQLSERVERRS01:80/Reports_APPL1
.
SSRS nimmt beide Anforderungen aufgrund der *:80
Konfiguration 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
Sicherheitsüberlegungen für einen
Artikel zur SQL Server-Installationsbasis .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.Konfigurieren einer Windows-Firewall für den Zugriff auf das Datenbankmodul
Kein Wort der verwendeten IP-Adressen.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.
Auswahl der Quell-IP-Adresse auf einem Multi-Homed-Windows-Computer
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 APPL1
und 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
quelle
Antworten:
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
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:
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.
Ziel-IP-Adressen und Binärnotation
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:
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:
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 ...
... 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
Leistungen
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
quelle
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!
quelle