Tl; Dr

Eu tenho uma instância do SQL Server (SQLSERVER01-i01) com um endereço IP e uma porta dedicados (162.xxx.xxx.51: 1433) em um SQL Server de várias instâncias (cada instância do SQL Server no Windows Server tem seu próprio endereço IP ), todos em execução em um servidor Windows (SQLSERVER01 / 162.xxx.xxx.50).

Também tenho uma instância dedicada do Reporting Services (SQLSERVERRS01-i01) com seu próprio endereço IP e porta (168.xxx.xxx.71: 1433), que está sendo executada em um servidor Windows diferente (SQLSERVERRS01) com seu próprio endereço IP (168 .xxx.xxx.70).

O servidor dedicado do Reporting Services possui um aplicativo APPL1que pode ser acessado via http://SQLSERVERRS01-i01:80/Reports_APPL1ou via http://SQLSERVERRS01:80/Reports_APPL1.

O SSRS atenderá as duas solicitações devido à *:80configuração na Configuração do Reporting Services para os cabeçalhos do host.

Temos vários firewalls entre cada intervalo de IPs, o que significa que precisamos aplicar uma regra específica para cada conexão IP para IP ou IPrange para IP. No entanto, quando dois servidores estão envolvidos, a segurança determina que sempre tenha que ser uma regra de IP para IP no firewall.

Questão

(com base na captura de tela mais abaixo)

Quando o servidor do Reporting Services se conecta à instância do SQL Server (em 162.xxx.xxx.51) para recuperar dados, ele sempre cria uma conexão com o endereço IP subjacente do servidor Windows (168.xxx.xxx.70 / preferido ) em que o SSRS está sendo executado ou (às vezes) usará o endereço IP da instância do SQL Server Reporting Services (168.xxx.xxx.71)?

Isso é relevante para a configuração da regra de firewall usando uma abordagem de IP para IP. Terei de solicitar uma regra que defina uma conexão 168.xxx.xxx.71 a 162.xxx.xxx.51 pela porta 1433 ou uma conexão 168.xxx.xxx.70 a 162.xxx.xxx.51 via porta 1433.

Atualmente, eu aplicaria as duas regras de firewall.

Pergunta bônus

Posso configurar o servidor do Reporting Services para se comunicar com um endereço IP dedicado? Nesse caso, com o endereço 168.xxx.xxx.71.

Respostas que não estou procurando

Não estou buscando conselhos sobre como otimizar a configuração do firewall ou como implementar um conceito de zoneamento para nossas redes. (Já está no pipeline). Além disso, não estou interessado em comentários que sugiram que o SQL Server e o SSRS no mesmo servidor resolveriam meus problemas. Eu sei disso e ficaria feliz em fazê-lo, exceto pelo software de terceiros necessário para executar junto com os componentes do SSRS.

Funciona

A configuração que eu tenho funciona se eu aplicar as duas regras de firewall entre a instância do SSRS e do SQL Server.

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

Quero reduzir com segurança por uma regra de firewall e garantir que tudo ainda funcione. (Veja a captura de tela mais abaixo)
Editar: Os artigos que li até agora sugerem que eu só preciso da segunda regra, mas não há garantia.

Artigos que já consultei

1. Considerações de segurança para um
   artigo da Base de Instalação do SQL Server .

2. Configurar o firewall do Windows para permitir acesso ao SQL Server
   Este artigo aponta para todos os outros artigos relacionados à configuração do firewall para o SQL Server.

3. Configurar um firewall do Windows para acesso ao mecanismo de banco de dados
   Nenhuma palavra de endereço IP usada.

4. Configurar um firewall para acesso ao servidor de relatório
   Este artigo foi bastante interessante, pois observou:

   Se você estiver acessando bancos de dados relacionais do SQL Server em computadores externos ou se o banco de dados do servidor de relatório estiver em uma instância externa do SQL Server, deverá abrir as portas 1433 e 1434 no computador externo.

   ... mas ainda não há uma palavra sobre configuração / configurações / padrões de IP.

5. Seleção de endereço IP de origem em um computador Windows com várias casas

6. A funcionalidade para seleção de endereço IP de origem no Windows Server 2008 e no Windows Vista difere da funcionalidade correspondente nas versões anteriores do Windows

Os artigos 5 e 6 foram gentilmente fornecidos a mim por James (dba.se). Atualmente, elas parecem ser as respostas mais apropriadas. No entanto, sou um pouco cético quanto ao fato de um artigo mencionar o uso de várias NICs, enquanto eu tenho apenas uma NIC com vários IPs atribuídos. Tom (dba.se) também comentou com conselhos e comentários gerais.

Por que aqui e não em dba.stackexchange.com

Inicialmente, relutei em postar essa pergunta no serverfault.com devido à natureza complexa da pergunta. A questão tem duas tendências: ser específica do SQL Server, mas também ser específica do Windows Server. Por fim, decidi publicá-lo aqui, porque acho que é um IP do Windows Server que lida com coisas (para perda de palavras melhores).

Se um moderador achar que vou obter uma resposta melhor no dba.stackexchange.com, mova a pergunta para lá.

A longa explicação

Em nosso ambiente, temos servidores Windows que hospedam várias instâncias do SQL Server e várias configurações de IP. Adicionamos configurações complexas de firewall, servidores dedicados do SQL Server Reporting Services (SSRS) e criamos um ambiente parecido com o seguinte:

Basicamente, podemos ter um Windows Server executando até 15 (quinze) instâncias do SQL Server em endereços IP individuais. O mesmo é válido para a instância dedicada do Reporting Services.

Regras de firewall

Atualmente, os diferentes intervalos de IP não estão configurados como zonas, o que significa que precisamos configurar cada regra de firewall independentemente como uma regra de IP para IP ou IPrange para IP. Quando dois servidores estão envolvidos, a segurança determina que sempre deve ser uma regra de IP para IP. Cada instância do SQL Server terá seu próprio conjunto de regras para os firewalls envolvidos nas comunicações, seja um link de servidor para servidor ou de cliente para servidor. A inscrição para uma regra de firewall atualmente exige um período de espera de quatro a seis semanas. Reduzir a quantidade de regras de firewall reduzirá a quantidade de pressão na equipe de segurança da rede.

Configuração de IP da instância do SQL Server

A configuração de uma instância do SQL Server para captar apenas um IP e uma porta dedicados é realizada modificando algumas configurações no utilitário SQL Server Configuration Manager. A primeira etapa é iniciar o SQL Server Configuation Manager e, na seção esquerda, selecione o SQL Server Network Configuration | Protocolos para InstanceName . No painel esquerdo, clique com o botão esquerdo no nome do protocolo TCP / IP e ative o protocolo. Em seguida, clique com o botão esquerdo no protocolo novamente e abra a janela Propriedades para TCP / IP .

Em seguida, verifique se as seguintes configurações estão definidas no registro do protocolo :

Enabled           : Yes
Listen All        : No

No registro de endereços IP, verifique as seguintes configurações para o endereço IP em questão (por exemplo, para o servidor Reporting Services neste exemplo, seria 168.xxx.xxx.71)

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

Nota: É importante que a configuração das portas dinâmicas TCP esteja vazia e não apenas 0 (zero).

Agora você tem uma instância do SQL Server que somente capturará conexões de banco de dados em 168.xxx.xxx.71 usando a porta 1433.

Resumo da Instância do SQL Server

O serviço Navegador do SQL Server não está em execução e cada instância individual do SQL Server está configurada para usar apenas seu próprio endereço IP na porta 1433. Dada uma instância do SQL Server chamada GENERAL, um servidor Windows com o nome do host SQLSERVER01 e dois endereços IP 162.xxx .xxx.50 (host) e 162.xxx.xxx.51 (SQL Instance) terminarei com os seguintes itens de configuração:

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

O SQL Server não receberá solicitações para 162.xxx.xxx.50: 1433, porque nenhuma instância do SQL Server está configurada para escutar esse endereço IP no utilitário SQL Server Configuration Manager. O SQL Server somente buscará solicitações para SQLSERVER01-i01 (na porta 1433) ou 162.xxx.xxx.51,1433.

Resumo da Instância do SQL Server Reporting Services

O serviço Navegador do SQL Server não está em execução e cada instância individual do SQL Server Reporting Services está configurada para usar apenas seu próprio endereço IP na porta 1433. Dada uma instância do SQL Server Reporting Services chamada GENERAL, um servidor Windows com o nome do host SQLSERVERRS01, um aplicativo no SSRS nomeado APPL1e em dois endereços IP 168.xxx.xxx.70 (host) e 168.xxx.xxx.71 (Instância SQL), terminarei com os seguintes itens de configuração:

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

O SQL Server não receberá solicitações para 168.xxx.xxx.70: 1433, porque nenhuma instância do SQL Server está configurada para escutar esse endereço IP no utilitário SQL Server Configuration Manager. O SQL Server captará apenas solicitações para SQLSERVER01-i01 (na porta 1433) ou 162.xxx.xxx.71,1433.

O SSRS selecionará solicitações para http: // sqlserverrs01-i01 / Reports_APPL1 ou http: // sqlserverrs01 / Reports_APPL1 devido à configuração *: 80 na configuração do Reporting Services para os cabeçalhos de host.

Espero ter fornecido informações suficientes para qualquer pessoa disposta a gastar seu tempo escrevendo uma resposta e aguardo seus detalhes e links técnicos.

Escrito com StackEdit e posteriormente modificado manualmente para ser compatível com stackexchange .

História

Edit 1 : Release inicial
Edit 2 : Reformatted para facilitar a leitura. A explicação SF / DB foi movida para baixo. Adicionado nome de host para o Windows Server
Edit 3 : corrigidos endereços IP incorretos na listagem de regras de firewall.
Edição 4 : alterou a palavra hospedagem para execução (é um ambiente não virtualizado) em alguns lugares. Adicionado endereço IP em uma única frase
Editar 5 : Adicionada uma lista de artigos que já consultei e referenciei o suporte
Editar 6 : Seção Histórico limpo

Introdução

De acordo com os vários documentos que encontrei durante minha pesquisa inicial e os documentos fornecidos em links e discussões, criei uma solução sólida, confiável e compatível.

RFC 3484

As comparações binárias realizadas mais adiante e as regras aplicadas estão de acordo com a RFC 3484, que aparentemente também é válida para endereços IPv4.

A RFC 3484 também afirma logo após a Regra 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.

Seleção de endereço IP de origem em um computador Windows com várias casas

Agora nem todas as regras da RFC 3484 se aplicam aos endereços IPv4. O artigo Microsoft Blog, a seleção do endereço IP de origem em um computador com vários hosts do Windows explica quais regras se aplicam.

Há uma pequena seção logo abaixo do Comportamento do Windows Vista / Windows Server 2008 que diz:

Semelhante ao XP, quando um programa não especifica um IP de origem, a pilha faz referência ao endereço IP de destino e examina toda a tabela de rotas IP para que ele possa escolher o melhor adaptador de rede para o qual enviar o pacote. Após a escolha do adaptador de rede, a pilha usa o processo de seleção de endereço definido na RFC 3484 e usa esse endereço IP como o endereço IP de origem dos pacotes de saída.

Visto que eu tenho apenas uma NIC na instância SQL / SSRS, a primeira parte é discutível. O Windows Server sempre escolherá a única NIC disponível.

Até o momento, a combinação da RFC 3484 com o Microsoft Blog faz com que os dois endereços IP sejam candidatos válidos para o endereço IP de origem. A explicação segue mais abaixo na resposta.

The Cable Guy

Um artigo do Cable Guy Os modelos de host forte e fraco do Cable Guy detalham como a seleção de IP funciona em um ambiente de envio e recebimento de host forte e em um ambiente de envio e recebimento de host fraco . Uma boa leitura adicional, mas não esclarece mais como o IP de origem é selecionado. O artigo refere-se à já conhecida RFC 3484.

Explicando o inexplicável

Para explicar a solução, primeiro precisamos converter os endereços IP em questão em seus equivalentes binários. Como não forneci gateways na minha pergunta, assumirei dois valores.

Endereços IP de origem e notação binária

Aqui está uma lista dos valores binários convertidos para os endereços IP envolvidos.

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

Endereços IP de destino e notação binária

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

Exemplo 1: IP do gateway menor que o IP da instância SQL / SSRS

Neste exemplo, vou assumir que o endereço IP do gateway é menor que o endereço IP da instância do SQL Server / SSRS, ou seja, 168.001.001.002.

Se você comparar os endereços binários da instância do Windows Server e do SQL Server / SSRS, terá o seguinte:

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)

Exemplo de resultado 1

Neste exemplo, os dois endereços IP têm a mesma quantidade de bits de ordem superior correspondentes (ou o prefixo de correspondência mais longo). Até agora, o processo http.sys usará um dos endereços IP para comunicações de saída.

Exemplo 2: IP do gateway maior que o IP da instância SQL / SSRS

Neste exemplo, vou assumir que o endereço IP do gateway é maior que o endereço IP da instância do SQL Server / SSRS, ou seja, 168.001.001.100.

Se você comparar os endereços binários da instância do Windows Server e do SQL Server / SSRS, terá o seguinte:

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)

Exemplo de resultado 2

Embora o endereço IP do gateway agora seja maior que o endereço IP do servidor Windows e da instância SQL / SSRS, a quantidade de bits de ordem superior correspondentes (ou prefixo de correspondência mais longo) ainda é a mesma. Até agora, o processo http.sys usará um dos endereços IP para comunicações de saída.

Resumo das descobertas até o momento

Até o momento, é impossível saber qual endereço IP o processo http.sys usará para as comunicações de saída em execução na instância SQL / SSRS (.71) no servidor Windows (.70).

"Quando você elimina o impossível, tudo o que resta, por mais improvável que seja, deve ser a verdade" - Sherlock Holmes

Há situações em que o endereço IP de origem pode ser definitivamente definido / selecionado / definido com o conhecimento RFC e Microsoft mencionado acima. Mas se os endereços IP estiverem muito próximos um do outro e próximos ao gateway, tudo será apenas uma questão de sorte. Ou é?

Visto que estou na posição de fazer as regras (firewall) e a Microsoft tem um ...

A implementação (que) tem outros meios de escolher entre os endereços de origem. Por exemplo, se a implementação souber de alguma forma qual endereço de origem resultará no "melhor" desempenho das comunicações.

... então tudo o que preciso fazer para determinar o endereço IP do processo http.sys é criar apenas uma regra de firewall com o endereço IP desejado.

O que acontece

1. Defino uma regra de firewall de 168.xxx.xxx.71 a 168.xxx.xxx.51: 1433
2. O componente http.sys da instância SQL / SSRS está em conformidade com a RFC 3484 e seleciona o IP de origem de acordo com as regras definidas
3. O endereço IP 168.xxx.xxx.71 (na NIC1) é determinado como o endereço IP de origem para alcançar o endereço IP 168.xxx.xxx.51 através da porta 1433 e, portanto, é atribuído a todos os pacotes de saída

Benefícios

1. Não estou interferindo de maneira alguma na implementação da RFC 3484
2. Não estou de maneira alguma fazendo malabarismos com rotas ou configurações de ARP
3. Estou em conformidade com a RFC 3484 e a implementação da Microsoft
4. Não estou invadindo nenhuma configuração do registro ou sistema
5. TENHO UMA REGRA DE FIREWALL MENOS

Verificação

Ainda tenho que remover o endereço IP das regras de firewall, mas estou confiante de que funcionará conforme projetado / definido. Um resumo seguirá.

História

Editar 1 Postagem inicial
Editar 2 Resposta limpa, seção Histórico adicionada

O SSRS suporta várias fontes de dados padrão, bem como outras fontes de dados .NET:

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

Supondo que você esteja usando o cliente nativo SQL para a fonte de dados, não há opção para especificar um endereço IP de origem:

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

Portanto, é lógico que o cliente usará IPADDR_ANY durante o método Bind () ao configurar a conexão de rede. Isso deixa o Windows para tomar a decisão.

A seleção de endereços do Windows 2008 e posteriores é baseada no maior número de bits correspondentes no próximo salto, o que significa que a resposta depende do seu gateway padrão (ou de quaisquer rotas específicas que você possa ter definido).

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

Eu não vi nenhuma menção de rotas ou gateways no seu diagrama, portanto é o mais longe que pude chegar.

Boa sorte!