Tl; Dr

J'ai une instance SQL Server (SQLSERVER01-i01) avec une adresse IP et un port dédiés (162.xxx.xxx.51: 1433) sur un serveur SQL multi-instance (chaque instance SQL Server sur Windows Server a sa propre adresse IP ) qui s'exécutent tous sur un serveur Windows (SQLSERVER01 / 162.xxx.xxx.50).

J'ai également une instance dédiée de Reporting Services (SQLSERVERRS01-i01) avec sa propre adresse IP et son propre port (168.xxx.xxx.71: 1433), qui s'exécute sur un serveur Windows différent (SQLSERVERRS01) avec sa propre adresse IP (168 .xxx.xxx.70).

Le serveur dédié Reporting Services dispose d'une application APPL1accessible via http://SQLSERVERRS01-i01:80/Reports_APPL1ou via http://SQLSERVERRS01:80/Reports_APPL1.

SSRS récupérera les deux demandes en raison de la *:80configuration dans la configuration de Reporting Services pour les en-têtes d'hôte.

Nous avons plusieurs pare-feu entre chaque plage IP, ce qui signifie que nous devons appliquer une règle spécifique pour chaque connexion IP à IP ou IPrange à IP. Cependant, lorsque deux serveurs sont impliqués, la sécurité impose que ce soit toujours une règle IP à IP dans le pare-feu.

Question

(basé sur une capture d'écran plus bas)

Lorsque le serveur Reporting Services se connecte à l'instance SQL Server (sur 162.xxx.xxx.51) pour récupérer des données, établit-il toujours une connexion avec l'adresse IP sous-jacente du serveur Windows (168.xxx.xxx.70 / préféré ) sur lequel SSRS s'exécute ou utilisera-t-il (parfois) l'adresse IP de l'instance SQL Server Reporting Services (168.xxx.xxx.71)?

Ceci est pertinent pour la configuration de la règle de pare-feu à l'aide d'une approche IP à IP. Je devrai soit demander une règle qui définit une connexion 168.xxx.xxx.71 à 162.xxx.xxx.51 via le port 1433 ou une connexion 168.xxx.xxx.70 à 162.xxx.xxx.51 via port 1433.

Actuellement, je demanderais les deux règles de pare-feu.

Question bonus

Puis-je configurer le serveur Reporting Services pour communiquer avec une adresse IP dédiée? Dans ce cas avec l'adresse 168.xxx.xxx.71.

Réponses que je ne cherche pas

Je ne cherche pas de conseils sur la façon d'optimiser la configuration du pare-feu ou de mettre en œuvre un concept de zonage pour nos réseaux. (C'est déjà dans le pipeline). De plus, je ne suis pas intéressé par les commentaires suggérant qu'avoir SQL Server et SSRS sur le même serveur résoudrait mes problèmes. Je le sais et je le ferais volontiers, mais pour le logiciel tiers requis pour fonctionner avec les composants SSRS.

Ça marche

La configuration que j'ai fonctionne si j'applique les deux règles de pare-feu entre l'instance SSRS et SQL Server.

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

Je veux réduire en toute sécurité d'une règle de pare-feu et m'assurer que tout fonctionne toujours. (Voir capture d'écran plus bas)
Edit: Les articles que j'ai lus jusqu'à présent suggèrent que je n'ai besoin que de la deuxième règle, mais il n'y a aucune garantie.

Articles que j'ai déjà consultés

1. Considérations sur la sécurité pour un
   article de base d' installation de SQL Server .

2. Configurer le pare-feu Windows pour autoriser l'accès à SQL Server
   Cet article pointe vers tous les autres articles concernant la configuration du pare-feu pour SQL Server.

3. Configurer un pare-feu Windows pour l'accès au moteur de base de données
   Aucun mot d'adresse IP utilisé.

4. Configurer un pare-feu pour l'accès au serveur de rapports
   Cet article était assez intéressant car il indiquait:

   Si vous accédez à des bases de données relationnelles SQL Server sur des ordinateurs externes ou si la base de données du serveur de rapports se trouve sur une instance SQL Server externe, vous devez ouvrir les ports 1433 et 1434 sur l'ordinateur externe.

   ... mais toujours pas un mot sur la configuration IP / les paramètres / les valeurs par défaut.

5. Sélection de l'adresse IP source sur un ordinateur Windows multirésident

6. La fonctionnalité de sélection de l'adresse IP source dans Windows Server 2008 et Windows Vista diffère de la fonctionnalité correspondante dans les versions antérieures de Windows

Les articles 5 et 6 m'ont été aimablement fournis par James (dba.se). Ils semblent actuellement être les réponses les plus appropriées. Je suis cependant un peu sceptique qu'un article mentionne l'utilisation de plusieurs cartes réseau alors que je n'ai qu'une seule carte réseau avec plusieurs adresses IP qui lui sont affectées. Tom (dba.se) a également apporté des conseils et des commentaires généraux.

Pourquoi ici et pas sur dba.stackexchange.com

J'étais réticent au début à poster cette question dans serverfault.com en raison de la nature complexe de la question. La question a à la fois tendance à être spécifique à SQL Server, mais aussi à être spécifique à Windows Server. Finalement, j'ai décidé de le poster ici, car je pense que c'est un truc de gestion IP Windows Server (pour la perte de meilleurs mots).

Si un modérateur pense que j'obtiendrai une meilleure réponse sur dba.stackexchange.com, veuillez déplacer la question là-bas.

La longue explication

Dans notre environnement, nous avons des serveurs Windows hébergeant plusieurs instances SQL Server et plusieurs paramètres IP. Nous ajoutons des configurations de pare-feu complexes, des serveurs dédiés SQL Server Reporting Services (SSRS) et proposons un environnement qui ressemble un peu à ceci:

Fondamentalement, nous pouvons avoir un serveur Windows exécutant jusqu'à 15 (quinze) instances SQL Server sur des adresses IP individuelles. Il en va de même pour l'instance dédiée de Reporting Services.

Règles de pare-feu

Les différentes plages IP ne sont actuellement pas configurées en tant que zones, ce qui signifie que nous devons configurer chaque règle de pare-feu indépendamment en tant que règle IP-à-IP ou IPrange-à-IP. Lorsque deux serveurs sont impliqués, la sécurité impose que ce soit toujours une règle IP-à-IP. Chaque instance de SQL Server aura son propre ensemble de règles pour les pare-feu impliqués dans les communications, qu'il s'agisse d'une liaison serveur à serveur ou client à serveur. La demande d'une règle de pare-feu entraîne actuellement une période d'attente de quatre à six semaines. Réduire le nombre de règles de pare-feu réduira la pression sur l'équipe de sécurité du réseau.

Configuration IP d'instance SQL Server

La configuration d'une instance SQL Server pour qu'elle ne soit récupérée que sur une IP et un port dédiés est effectuée en modifiant certains paramètres dans l'utilitaire SQL Server Configuration Manager. La première étape consiste à démarrer le Gestionnaire de configuration SQL Server et dans la section de gauche, sélectionnez Configuration réseau SQL Server | Protocoles pour InstanceName . Dans le volet gauche, cliquez avec le bouton gauche sur le nom du protocole TCP / IP et activez le protocole. Cliquez ensuite à nouveau avec le bouton gauche sur le protocole et ouvrez la fenêtre Propriétés de TCP / IP .

Assurez-vous ensuite que les paramètres suivants sont définis dans le registre de protocole :

Enabled           : Yes
Listen All        : No

Dans le registre des adresses IP, vérifiez les paramètres suivants pour l'adresse IP en question (par exemple, pour le serveur Reporting Services dans cet exemple, ce serait pour 168.xxx.xxx.71)

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

Remarque: Il est important que le paramètre pour les ports dynamiques TCP soit vide et pas seulement un 0 (zéro).

Vous disposez maintenant d'une instance SQL Server qui ne récupérera que les connexions à la base de données sur 168.xxx.xxx.71 à l'aide du port 1433.

Résumé de l'instance SQL Server

Le service SQL Server Browser n'est pas en cours d'exécution et chaque instance SQL Server individuelle est configurée pour utiliser uniquement sa propre adresse IP sur le port 1433. Étant donné une instance SQL Server appelée GENERAL, un serveur Windows avec le nom d'hôte SQLSERVER01 et deux adresses IP 162.xxx .xxx.50 (hôte) et 162.xxx.xxx.51 (instance SQL) Je vais me retrouver avec les éléments de configuration suivants:

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

Le serveur SQL ne récupérera pas les demandes pour 162.xxx.xxx.50: 1433, car aucune instance SQL Server n'est configurée pour écouter sur cette adresse IP dans l'utilitaire SQL Server Configuration Manager. Le serveur SQL récupère uniquement les demandes pour SQLSERVER01-i01 (sur le port 1433) ou 162.xxx.xxx.51,1433.

Résumé de l'instance de SQL Server Reporting Services

Le service SQL Server Browser n'est pas en cours d'exécution et chaque instance individuelle de SQL Server Reporting Services est configurée pour utiliser uniquement sa propre adresse IP sur le port 1433. Étant donné une instance de SQL Server Reporting Services appelée GENERAL, un serveur Windows avec le nom d'hôte SQLSERVERRS01, une application sur le SSRS nommé APPL1et deux adresses IP 168.xxx.xxx.70 (hôte) et 168.xxx.xxx.71 (instance SQL), je vais me retrouver avec les éléments de configuration suivants:

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

Le serveur SQL ne récupérera pas les demandes pour 168.xxx.xxx.70: 1433, car aucune instance SQL Server n'est configurée pour écouter sur cette adresse IP dans l'utilitaire SQL Server Configuration Manager. Le serveur SQL récupère uniquement les demandes pour SQLSERVER01-i01 (sur le port 1433) ou 162.xxx.xxx.71,1433.

SSRS récupérera les demandes pour http: // sqlserverrs01-i01 / Reports_APPL1 ou http: // sqlserverrs01 / Reports_APPL1 en raison de la configuration *: 80 dans la configuration de Reporting Services pour les en-têtes d'hôte.

J'espère avoir fourni suffisamment d'informations pour quiconque souhaite passer son temps à rédiger une réponse et j'attends avec impatience vos détails techniques et vos liens.

Écrit avec StackEdit et ultérieurement modifié manuellement pour être compatible avec stackexchange.

Histoire

Edit 1 : Initial Release
Edit 2 : Reformaté pour plus de lisibilité. Explication déplacée SF / DB vers le bas. Nom d'hôte ajouté pour Windows Server
Edit 3 : correction des adresses IP incorrectes dans la liste des règles de pare-feu.
Edit 4 : changé le mot d'hébergement en exécutant (c'est un environnement non virtualisé) à certains endroits. Ajout d'une adresse IP dans une phrase unique
Edit 5 : Ajout d'une liste d'articles que j'ai déjà consultés et référencé le support
Edit 6 : Nettoyage de la section Historique

introduction

D'après les différents documents que j'ai trouvés lors de mes recherches initiales et les documents fournis dans les liens et les discussions, j'ai trouvé une solution solide, fiable et conforme.

RFC 3484

Les comparaisons binaires effectuées plus bas et les règles appliquées sont conformes à la RFC 3484 qui est apparemment également valable pour les adresses IPv4.

La RFC 3484 indique également juste après la règle 8 que

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.

Sélection de l'adresse IP source sur un ordinateur Windows multirésident

Désormais, toutes les règles de la RFC 3484 ne s'appliquent pas aux adresses IPv4. L'article de blog Microsoft sur la sélection de l'adresse IP source sur un ordinateur Windows multi-hébergé explique quelles règles s'appliquent.

Il y a une petite section juste en dessous du comportement de Windows Vista / Windows Server 2008 qui se lit comme suit:

Semblable à XP lorsque si un programme ne spécifie pas d'adresse IP source, la pile fait référence à l'adresse IP cible, puis examine l'ensemble de la table de routage IP afin qu'il puisse choisir la meilleure carte réseau sur laquelle envoyer le paquet. Une fois la carte réseau choisie, la pile utilise le processus de sélection d'adresse défini dans RFC 3484 et utilise cette adresse IP comme adresse IP source pour les paquets sortants.

Étant donné que je n'ai qu'une seule carte réseau dans l'instance SQL / SSRS, la première partie est théorique. Windows Server choisira toujours la seule carte réseau disponible.

Jusqu'à présent, la combinaison de la RFC 3484 avec le blog Microsoft a pour résultat que les deux adresses IP sont des candidats valides pour l'adresse IP source. L'explication suit plus loin dans la réponse.

Le gars du cable

Un article de Cable Guy The Cable Guy Strong and Weak Host Models explique plus en détail comment fonctionne la sélection IP dans un environnement d' envoi et de réception d'hôte fort et dans un environnement d' envoi et de réception d'hôte faible . Une bonne lecture supplémentaire, mais ne fait plus la lumière sur la façon dont l'IP source est sélectionnée. L'article concerne la RFC 3484 déjà connue.

Expliquer l'inexplicable

Afin d'expliquer la solution, nous devons d'abord convertir les adresses IP en question en leurs équivalents binaires. Étant donné que je n'ai pas fourni de passerelles dans ma question, je suppose deux valeurs.

Adresses IP source et notation binaire

Voici une liste des valeurs binaires converties pour les adresses IP impliquées.

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

Adresses IP cibles et notation binaire

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

Exemple 1: IP de passerelle inférieure à IP d'instance SQL / SSRS

Dans cet exemple, je vais supposer que l'adresse IP de la passerelle est inférieure à l'adresse IP de l'instance SQL Server / SSRS, à savoir 168.001.001.002.

Si vous comparez les deux adresses binaires de l'instance de Windows Server et SQL Server / SSRS, vous disposez des éléments suivants:

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)

Exemple de résultat 1

Dans cet exemple, les deux adresses IP ont la même quantité de bits de poids fort correspondants (ou le préfixe de correspondance le plus long). Jusqu'à présent, le processus http.sys utilisera l'une des adresses IP pour les communications sortantes.

Exemple 2: IP de passerelle supérieure à IP d'instance SQL / SSRS

Dans cet exemple, je vais supposer que l'adresse IP de la passerelle est supérieure à l'adresse IP de l'instance SQL Server / SSRS, à savoir 168.001.001.100.

Si vous comparez les deux adresses binaires de l'instance de Windows Server et SQL Server / SSRS, vous disposez des éléments suivants:

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)

Exemple de résultat 2

Même si l'adresse IP de la passerelle est désormais supérieure à l'adresse IP du serveur Windows et de l'instance SQL / SSRS, la quantité de bits de poids fort correspondants (ou le préfixe de correspondance le plus long) est toujours la même. Jusqu'à présent, le processus http.sys utilisera l'une des adresses IP pour les communications sortantes.

Résumé des résultats à ce jour

Jusqu'à présent, il est impossible de dire quelle adresse IP le processus http.sys utilisera pour les communications sortantes s'exécutant sur l'instance SQL / SSRS (.71) sur le serveur Windows (.70).

"Quand vous avez éliminé l'impossible, tout ce qui reste, aussi improbable soit-il, doit être la vérité" - Sherlock Holmes

Il y a des situations où l'adresse IP source peut certainement être précise / sélectionnée / définie avec les connaissances RFC et Microsoft susmentionnées. Mais si les adresses IP sont tout simplement trop proches les unes des autres et près de la passerelle, eh bien, tout dépend de la chance. Ou est-ce?

Vu que je suis en mesure de faire les règles (pare-feu) et Microsoft a un ...

l'implémentation (qui) a d'autres moyens de choisir parmi les adresses sources. Par exemple, si l'implémentation sait d'une manière ou d'une autre quelle adresse source se traduira par les "meilleures" performances de communication.

... alors tout ce que j'ai à faire pour déterminer l'adresse IP du processus http.sys est de créer une seule règle de pare-feu avec l'adresse IP souhaitée.

Ce qui se produit

1. Je définis une règle de pare-feu de 168.xxx.xxx.71 à 168.xxx.xxx.51: 1433
2. Le composant http.sys de l'instance SQL / SSRS est conforme à la RFC 3484 et sélectionne l'IP source selon les règles définies
3. L'adresse IP 168.xxx.xxx.71 (sur NIC1) est déterminée comme l'adresse IP source pour atteindre l'adresse IP 168.xxx.xxx.51 via le port 1433 et est ainsi affectée à tous les paquets sortants

Avantages

1. Je n'interfère en aucune façon avec la mise en œuvre de la RFC 3484
2. Je ne jongle en aucun cas avec des routes ou des configurations ARP
3. Je suis conforme à la RFC 3484 et à l'implémentation de Microsoft
4. Je ne pirate aucun paramètre de registre ou configuration système
5. J'AI UNE RÈGLE PARE-FEU DE MOINS

Vérification

Je n'ai pas encore supprimé l'adresse IP des règles de pare-feu, mais je suis convaincu qu'elle fonctionnera comme prévu / défini. Un résumé suivra.

Histoire

Modifier 1 Message initial
Modifier 2 Réponse nettoyée, section Historique ajoutée

SSRS prend en charge plusieurs sources de données standard ainsi que d'autres sources de données .NET:

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

En supposant que vous utilisez le client natif SQL pour la source de données, vous n'avez pas la possibilité de spécifier une adresse IP source:

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

Par conséquent, il va de soi que le client utilisera IPADDR_ANY pendant la méthode Bind () lors de la configuration de la connexion réseau. Cela laisse Windows pour prendre la décision.

La sélection d'adresse Windows 2008 et versions ultérieures est basée sur le plus grand nombre de bits correspondants avec le saut suivant, ce qui signifie que la réponse dépend de votre passerelle par défaut (ou de toutes les routes spécifiques que vous avez définies).

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

Je n'ai vu aucune mention d'itinéraires ou de passerelles dans votre diagramme, donc c'est aussi loin que j'ai pu.

Bonne chance!