Tl; Dr

Tengo una instancia de SQL Server (SQLSERVER01-i01) con una dirección IP y un puerto dedicados (162.xxx.xxx.51: 1433) en un servidor SQL de varias instancias (cada instancia de SQL Server en Windows Server tiene su propia dirección IP ) que se ejecutan en un servidor Windows (SQLSERVER01 / 162.xxx.xxx.50).

También tengo una instancia dedicada de Reporting Services (SQLSERVERRS01-i01) con su propia dirección IP y puerto (168.xxx.xxx.71: 1433), que se ejecuta en un servidor Windows diferente (SQLSERVERRS01) con su propia dirección IP (168 .xxx.xxx.70).

El servidor dedicado de Reporting Services tiene una aplicación a la APPL1que se puede acceder a través de http://SQLSERVERRS01-i01:80/Reports_APPL1o vía http://SQLSERVERRS01:80/Reports_APPL1.

SSRS recogerá ambas solicitudes debido a la *:80configuración en la Configuración de Reporting Services para los encabezados de host.

Tenemos varios firewalls entre cada rango de IP, lo que significa que tenemos que solicitar una regla específica para cada conexión de IP a IP o de rango de IP a IP. Sin embargo, cuando hay dos servidores involucrados, la seguridad dicta que siempre debe ser una regla de IP a IP en el firewall.

Pregunta

(basado en la captura de pantalla más abajo)

Cuando el servidor de Reporting Services se conecta a la instancia de SQL Server (en 162.xxx.xxx.51) para recuperar datos, siempre creará una conexión con la dirección IP subyacente del servidor de Windows (168.xxx.xxx.70 / preferido ) en el que se ejecuta SSRS, o ¿utilizará (a veces) la dirección IP de la instancia de SQL Server Reporting Services (168.xxx.xxx.71)?

Esto es relevante para la configuración de la regla de firewall utilizando un enfoque de IP a IP. Tendré que solicitar una regla que defina una conexión 168.xxx.xxx.71 a 162.xxx.xxx.51 a través del puerto 1433 o una conexión 168.xxx.xxx.70 a 162.xxx.xxx.51 a través de puerto 1433.

Actualmente, solicitaría ambas reglas de firewall.

Pregunta extra

¿Puedo configurar el servidor de Reporting Services para comunicarse con una dirección IP dedicada? En este caso con la dirección 168.xxx.xxx.71.

Respuestas que no estoy buscando

No busco consejos sobre cómo optimizar la configuración del firewall o cómo implementar un concepto de zonificación para nuestras redes. (Ya está en la tubería). Además, no me interesan los comentarios que sugieren que tener SQL Server y SSRS en el mismo servidor resolvería mis problemas. Lo sé y con gusto lo haría, pero para el software de terceros requerido para ejecutarse junto con los componentes SSRS.

Funciona

La configuración que tengo funciona si aplico ambas reglas de firewall entre SSRS y la instancia de SQL Server.

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

Quiero reducir de forma segura una regla de firewall y asegurarme de que todo seguirá funcionando. (Ver captura de pantalla más abajo)
Editar: Los artículos que he leído hasta ahora sugieren que solo necesito la segunda regla, pero no hay garantía.

Artículos que ya he consultado

1. Consideraciones de seguridad para un
   artículo de Base de instalación de SQL Server .

2. Configure el Firewall de Windows para permitir el acceso a SQL Server
   Este artículo hace referencia a todos los demás artículos relacionados con la configuración del firewall para SQL Server.

3. Configure un Firewall de Windows para el acceso al motor de la base de datos
   No se utiliza ninguna palabra de las direcciones IP.

4. Configurar un firewall para el acceso al servidor de informes
   Este artículo fue bastante interesante, ya que señaló:

   Si está accediendo a bases de datos relacionales de SQL Server en computadoras externas, o si la base de datos del servidor de informes está en una instancia externa de SQL Server, debe abrir los puertos 1433 y 1434 en la computadora externa.

   ... pero aún no hay una palabra sobre la configuración / configuración / valores predeterminados de IP.

5. Selección de la dirección IP de origen en una computadora con Windows de alojamiento múltiple

6. La funcionalidad para la selección de la dirección IP de origen en Windows Server 2008 y en Windows Vista difiere de la funcionalidad correspondiente en versiones anteriores de Windows

Los artículos 5 y 6 fueron amablemente proporcionados por James (dba.se). Actualmente parecen ser las respuestas más apropiadas. Sin embargo, estoy un poco escéptico de que un artículo mencione el uso de múltiples NIC, mientras que solo tengo una NIC con varias IP asignadas. Tom (dba.se) también ha aportado consejos y comentarios generales.

¿Por qué aquí y no en dba.stackexchange.com?

Al principio era reacio a publicar esta pregunta en serverfault.com debido a la naturaleza compleja de la pregunta. La pregunta tiene ambas tendencias a ser específica de SQL Server, pero también a ser específica de Windows Server. Finalmente, decidí publicarlo aquí, porque creo que es una cosa de manejo de IP de Windows Server (por pérdida de mejores palabras).

Si un moderador cree que obtendré una mejor respuesta en dba.stackexchange.com, mueva la pregunta allí.

La larga explicación

En nuestro entorno tenemos servidores Windows que alojan múltiples instancias de SQL Server y múltiples configuraciones de IP. Agregamos configuraciones complejas de firewall, servidores dedicados de SQL Server Reporting Services (SSRS) y creamos un entorno que se parece un poco a esto:

Básicamente, podemos tener un Windows Server que ejecute hasta 15 (quince) instancias de SQL Server en direcciones IP individuales. Lo mismo es válido para la instancia dedicada de Reporting Services.

Reglas de cortafuegos

Los diferentes rangos de IP actualmente no están configurados como zonas, lo que significa que tenemos que configurar cada regla de firewall independientemente como una regla de IP a IP o de rango de IP a IP. Cuando hay dos servidores involucrados, la seguridad dicta que siempre debe ser una regla de IP a IP. Cada instancia de SQL Server tendrá su propio conjunto de reglas para los firewalls involucrados en las comunicaciones, ya sea un enlace de servidor a servidor o de cliente a servidor. Solicitar una regla de firewall actualmente incurre en un período de espera de cuatro a seis semanas. La reducción de la cantidad de reglas de firewall reducirá la presión sobre el equipo de seguridad de la red.

Configuración de IP de instancia de SQL Server

La configuración de una instancia de SQL Server para recoger solo en una IP dedicada y un puerto se realiza modificando algunas configuraciones en la utilidad Administrador de configuración de SQL Server. El primer paso es iniciar el Administrador de configuración de SQL Server y en la sección izquierda, seleccione la Configuración de red de SQL Server | Protocolos para InstanceName . En el panel izquierdo, haga clic con el botón izquierdo en el nombre del protocolo TCP / IP y habilite el protocolo. Luego, haga clic de nuevo en el protocolo y abra la ventana Propiedades para TCP / IP .

Luego asegúrese de que las siguientes configuraciones estén establecidas en el registro de Protocolo :

Enabled           : Yes
Listen All        : No

En el registro de direcciones IP, verifique la siguiente configuración para la dirección IP en cuestión (por ejemplo, para el servidor de Reporting Services en este ejemplo sería para 168.xxx.xxx.71)

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

Nota: es importante que la configuración de los puertos dinámicos TCP esté vacía, no solo un 0 (cero).

Ahora tiene una instancia de SQL Server que solo recogerá las conexiones de la base de datos en 168.xxx.xxx.71 utilizando el puerto 1433.

Resumen de instancia de SQL Server

El servicio del navegador SQL Server no se está ejecutando y cada instancia individual de SQL Server está configurada para usar solo su propia dirección IP en el puerto 1433. Dada una instancia de SQL Server llamada GENERAL, un servidor Windows con el nombre de host SQLSERVER01 y dos direcciones IP 162.xxx .xxx.50 (host) y 162.xxx.xxx.51 (instancia de SQL) terminaré con los siguientes elementos de configuración:

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 no aceptará solicitudes para 162.xxx.xxx.50: 1433, porque ninguna instancia de SQL Server está configurada para escuchar en esta dirección IP en la utilidad Administrador de configuración de SQL Server. SQL Server solo recogerá solicitudes para SQLSERVER01-i01 (en el puerto 1433) o 162.xxx.xxx.51,1433.

Resumen de la instancia de SQL Server Reporting Services

El servicio del navegador SQL Server no se está ejecutando y cada instancia individual de SQL Server Reporting Services está configurada para usar solo su propia dirección IP en el puerto 1433. Dada una instancia de SQL Server Reporting Services llamada GENERAL, un servidor de Windows con el nombre de host SQLSERVERRS01, una aplicación en el SSRS nombrado APPL1y dos direcciones IP 168.xxx.xxx.70 (host) y 168.xxx.xxx.71 (instancia de SQL) terminaré con los siguientes elementos de configuración:

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 no aceptará solicitudes para 168.xxx.xxx.70: 1433, porque ninguna instancia de SQL Server está configurada para escuchar en esta dirección IP en la utilidad Administrador de configuración de SQL Server. El servidor SQL solo aceptará solicitudes para SQLSERVER01-i01 (en el puerto 1433) o 162.xxx.xxx.71,1433.

SSRS recibirá solicitudes para http: // sqlserverrs01-i01 / Reports_APPL1 o http: // sqlserverrs01 / Reports_APPL1 debido a la configuración *: 80 en la configuración de Reporting Services para los encabezados de host.

Espero haber proporcionado suficiente información para cualquiera que esté dispuesto a pasar su tiempo escribiendo una respuesta y espero sus detalles técnicos y enlaces.

Escrito con StackEdit y luego modificado manualmente para ser compatible con stackexchange.

Historia

Edición 1 : Versión inicial
Edición 2 : Reformateado para facilitar la lectura. Explicación movida SF / DB abajo. Se agregó el nombre de host para Windows Server
Edit 3 : se corrigieron las direcciones IP incorrectas en la lista de reglas del firewall.
Edición 4 : cambió la palabra hosting a corriendo (es un entorno no virtualizado) en algunos lugares. Se agregó la dirección IP en una sola oración
Edición 5 : se agregó una lista de artículos que ya he consultado y se hizo referencia al soporte
Editar 6 : Se limpió la sección Historial

Introducción

De acuerdo con los diversos documentos que encontré durante mi investigación inicial y los documentos proporcionados en enlaces y discusiones, he encontrado una solución sólida, confiable y compatible.

RFC 3484

Las comparaciones binarias realizadas más abajo y las reglas aplicadas están de acuerdo con RFC 3484, que aparentemente también es válido para direcciones IPv4.

RFC 3484 también establece justo después de la Regla 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.

Selección de la dirección IP de origen en una computadora con Windows de alojamiento múltiple

Ahora no todas las reglas en el RFC 3484 se aplican a las direcciones IPv4. El artículo del blog de Microsoft La selección de la dirección IP de origen en una computadora con Windows con múltiples hosts explica qué reglas se aplican.

Hay una pequeña sección justo debajo del comportamiento de Windows Vista / Windows Server 2008 que dice:

Similar a XP cuando si un programa no especifica una IP de origen, la pila hace referencia a la dirección IP de destino y luego examina toda la tabla de rutas IP para que pueda elegir el mejor adaptador de red sobre el cual enviar el paquete. Una vez que se ha elegido el adaptador de red, la pila usa el proceso de selección de dirección definido en RFC 3484 y usa esa dirección IP como la dirección IP de origen para los paquetes salientes.

Al ver que solo tengo una NIC en la instancia de SQL / SSRS, la primera parte es discutible. Windows Server siempre elegirá la única NIC disponible.

Hasta ahora, la combinación de RFC 3484 con el blog de Microsoft da como resultado que ambas direcciones IP sean candidatos válidos para la dirección IP de origen. La explicación sigue más abajo en la respuesta.

El chico del cable

Un artículo de Cable Guy The Cable Guy Strong and Weak Host Models ofrece más detalles sobre cómo funciona la selección de IP en un entorno de envío y recepción de host fuerte y en un entorno de envío y recepción de host débil . Una buena lectura adicional, pero no arroja más luz sobre cómo se selecciona la IP de origen. El artículo se refiere al RFC 3484 ya conocido.

Explicando lo inexplicable

Para explicar la solución, primero tenemos que convertir las direcciones IP en cuestión a sus equivalentes binarios. Al ver que no proporcioné puertas de enlace en mi pregunta, asumiré dos valores.

Direcciones IP de origen y notación binaria

Aquí hay una lista de los valores binarios convertidos para las direcciones IP involucradas.

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

Direcciones IP de destino y notación binaria

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

Ejemplo 1: IP de puerta de enlace inferior a IP de instancia de SQL / SSRS

En este ejemplo, voy a suponer que la dirección IP de la puerta de enlace es menor que la dirección IP de la instancia de SQL Server / SSRS, es decir, 168.001.001.002.

Si compara ambas direcciones binarias de Windows Server y SQL Server / SSRS, entonces tiene lo siguiente:

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)

Resultado Ejemplo 1

En este ejemplo, ambas direcciones IP tienen la misma cantidad de bits de orden superior coincidentes (o el prefijo de coincidencia más largo). Hasta ahora, el proceso http.sys utilizará cualquiera de las direcciones IP para las comunicaciones salientes.

Ejemplo 2: IP de puerta de enlace superior a la IP de instancia de SQL / SSRS

En este ejemplo, voy a suponer que la dirección IP de la puerta de enlace es más alta que la dirección IP de la instancia de SQL Server / SSRS, es decir, 168.001.001.100.

Si compara ambas direcciones binarias de Windows Server y SQL Server / SSRS, entonces tiene lo siguiente:

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)

Resultado Ejemplo 2

Aunque la dirección IP de la puerta de enlace ahora es más alta que la dirección IP del servidor de Windows y la instancia de SQL / SSRS, la cantidad de bits de orden superior coincidentes (o el prefijo de coincidencia más largo) siguen siendo los mismos. Hasta ahora, el proceso http.sys utilizará cualquiera de las direcciones IP para las comunicaciones salientes.

Resumen de hallazgos hasta ahora

Hasta ahora, es imposible saber qué dirección IP utilizará el proceso http.sys para las comunicaciones salientes que se ejecutan en la instancia de SQL / SSRS (.71) en el servidor de Windows (.70).

"Cuando hayas eliminado lo imposible, lo que queda, por improbable que sea, debe ser la verdad" - Sherlock Holmes

Hay situaciones en las que la dirección IP de origen definitivamente puede ser puntiaguda / seleccionada / definida con el RFC y el conocimiento de Microsoft antes mencionados. Pero si las direcciones IP están demasiado cerca una de la otra y cerca de la puerta de enlace, todo es cuestión de suerte. ¿O es eso?

Viendo que estoy en la posición de hacer las reglas (firewall) y Microsoft tiene un ...

la implementación (que) tiene otros medios para elegir entre las direcciones de origen. Por ejemplo, si la implementación de alguna manera sabe qué dirección de origen dará como resultado el "mejor" rendimiento de las comunicaciones.

... entonces todo lo que tengo que hacer para determinar la dirección IP del proceso http.sys es crear solo una regla de firewall con la dirección IP deseada.

Lo que pasa

1. Defino una regla de firewall de 168.xxx.xxx.71 a 168.xxx.xxx.51: 1433
2. El componente http.sys de la instancia de SQL / SSRS cumple con RFC 3484 y selecciona la IP de origen de acuerdo con las reglas definidas
3. La dirección IP 168.xxx.xxx.71 (en NIC1) se determina como la dirección IP de origen para alcanzar la dirección IP 168.xxx.xxx.51 a través del puerto 1433 y, por lo tanto, se asigna a todos los paquetes salientes

Beneficios

1. De ninguna manera estoy interfiriendo con la implementación de RFC 3484
2. De ninguna manera estoy haciendo malabarismos con rutas o configuraciones ARP
3. Cumplo con RFC 3484 y la implementación de Microsoft
4. No estoy pirateando ninguna configuración de registro o configuración del sistema
5. Tengo una regla de fuego menos

Verificación

Todavía tengo que eliminar la dirección IP de las reglas del firewall, pero estoy seguro de que funcionará según lo diseñado / definido. Seguirá un resumen.

Historia

Editar 1 Publicación inicial
Editar 2 Respuesta limpiada, agregada sección Historial

SSRS admite varias fuentes de datos estándar, así como otras fuentes de datos .NET:

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

Suponiendo que está utilizando el cliente nativo de SQL para el origen de datos, no tiene opción para especificar una dirección IP de origen:

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

Por lo tanto, es lógico que el cliente use IPADDR_ANY durante el método Bind () al configurar la conexión de red. Esto deja a Windows para tomar la decisión.

La selección de direcciones de Windows 2008 y posteriores se basa en el mayor número de bits coincidentes con el siguiente salto, lo que significa que la respuesta depende de su puerta de enlace predeterminada (o cualquier ruta específica que haya definido).

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

No vi ninguna mención de rutas o puertas de enlace en su diagrama, así que eso es lo más lejos que pude llegar.

¡Buena suerte!