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
Consideraciones de seguridad para un
artículo de Base de instalación de SQL Server .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.Configure un Firewall de Windows para el acceso al motor de la base de datos
No se utiliza ninguna palabra de las direcciones IP.Configurar un firewall para el acceso al servidor de informes
Este artículo fue bastante interesante, ya que señaló:
... pero aún no hay una palabra sobre la configuración / configuración / valores predeterminados de IP.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.
Selección de la dirección IP de origen en una computadora con Windows de alojamiento múltiple
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
fuente
Respuestas:
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
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:
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.
Direcciones IP de destino y notación binaria
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:
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:
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 ...
... 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
Beneficios
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
fuente
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!
fuente