Tl; Dr

Ho un'istanza di SQL Server (SQLSERVER01-i01) con un indirizzo IP e una porta dedicati (162.xxx.xxx.51: 1433) su un SQL Server multiistanza (ogni istanza di SQL Server su Windows Server ha il proprio indirizzo IP ) che sono tutti in esecuzione su un server Windows (SQLSERVER01 / 162.xxx.xxx.50).

Ho anche un'istanza di Reporting Services dedicata (SQLSERVERRS01-i01) con il proprio indirizzo IP e porta (168.xxx.xxx.71: 1433), che è in esecuzione su un altro server Windows (SQLSERVERRS01) con il proprio indirizzo IP (168 .xxx.xxx.70).

Il server dedicato di Reporting Services ha un'applicazione APPL1che può essere raggiunta tramite http://SQLSERVERRS01-i01:80/Reports_APPL1o tramite http://SQLSERVERRS01:80/Reports_APPL1.

SSRS raccoglierà entrambe le richieste a causa della *:80configurazione nella configurazione di Reporting Services per le intestazioni host.

Abbiamo più firewall tra ogni intervallo IP, il che significa che dobbiamo applicare una regola specifica per ogni connessione IP-to-IP o IP-range-IP. Tuttavia, quando sono coinvolti due server, la sicurezza impone che debba sempre essere una regola da IP a IP nel firewall.

Domanda

(basato sulla schermata più in basso)

Quando il server Reporting Services si connette all'istanza di SQL Server (su 162.xxx.xxx.51) per recuperare i dati, creerà sempre una connessione con l'indirizzo IP sottostante del server Windows (168.xxx.xxx.70 / preferito ) su cui è in esecuzione SSRS o (a volte) utilizzerà l'indirizzo IP dell'istanza di SQL Server Reporting Services (168.xxx.xxx.71)?

Ciò è rilevante per la configurazione della regola firewall mediante un approccio IP-IP. Dovrò richiedere una regola che definisce una connessione da 168.xxx.xxx.71 a 162.xxx.xxx.51 tramite la porta 1433 o una connessione da 168.xxx.xxx.70 a 162.xxx.xxx.51 tramite porta 1433.

Attualmente vorrei applicare per entrambe le regole del firewall.

Domanda bonus

Posso configurare il server Reporting Services per comunicare con un indirizzo IP dedicato? In questo caso con l'indirizzo 168.xxx.xxx.71.

Risposte che non sto cercando

Non sto cercando consigli su come ottimizzare la configurazione del firewall o su come implementare un concetto di suddivisione in zone per le nostre reti. (È già in cantiere). Inoltre, non sono interessato al feedback che suggerisce che avere SQL Server e SSRS sullo stesso server risolverà i miei problemi. Lo so e lo farei volentieri, ma per il software di terze parti richiesto per funzionare insieme ai componenti SSRS.

Funziona

La configurazione che ho funziona se applico entrambe le regole del firewall tra l'istanza di SSRS e SQL Server.

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

Voglio ridurre in sicurezza con una regola del firewall e assicurarmi che tutto funzioni ancora. (Vedi lo screenshot più in basso)
Modifica: gli articoli che ho letto finora suggeriscono che ho solo bisogno della seconda regola, ma non c'è garanzia.

Articoli che ho già consultato

1. Considerazioni sulla sicurezza per un
   articolo della Base di installazione di SQL Server .

2. Configurare Windows Firewall per consentire l'accesso a SQL Server
   Questo articolo rimanda a tutti gli altri articoli riguardanti la configurazione del firewall per SQL Server.

3. Configurare un Windows Firewall per l'accesso al motore di database
   Nessuna parola di indirizzi IP utilizzata.

4. Configurare un firewall per l'accesso al server di report
   Questo articolo è stato piuttosto interessante in quanto ha osservato:

   Se si accede a database relazionali di SQL Server su computer esterni o se il database del server di report si trova su un'istanza esterna di SQL Server, è necessario aprire le porte 1433 e 1434 sul computer esterno.

   ... ma non ancora una parola sulla configurazione / impostazioni / impostazioni predefinite IP.

5. Selezione dell'indirizzo IP di origine su un computer Windows multihomed

6. La funzionalità per la selezione dell'indirizzo IP di origine in Windows Server 2008 e in Windows Vista differisce dalla funzionalità corrispondente nelle versioni precedenti di Windows

Gli articoli 5 e 6 mi sono stati gentilmente forniti da James (dba.se). Attualmente sembrano essere le risposte più appropriate. Sono tuttavia un po 'scettico sul fatto che un articolo menzioni l'uso di più schede di rete mentre ho solo una scheda di rete con più IP assegnati ad essa. Tom (dba.se) ha anche contribuito con consigli e commenti generali.

Perché qui e non in dba.stackexchange.com

All'inizio ero riluttante a pubblicare questa domanda in serverfault.com a causa della natura complessa della domanda. La domanda ha entrambe le tendenze ad essere specifiche di SQL Server, ma anche specifiche di Windows Server. Alla fine ho deciso di pubblicarlo qui, perché penso che sia un IP di Windows Server che gestisce cose (per la perdita di parole migliori).

Se un moderatore pensa che otterrò una risposta migliore in dba.stackexchange.com, ti preghiamo di spostare la domanda lì.

La lunga spiegazione

Nel nostro ambiente abbiamo server Windows che ospitano più istanze di SQL Server e più impostazioni IP. Aggiungiamo configurazioni firewall complesse, server dedicati SQL Server Reporting Services (SSRS) e creiamo un ambiente un po 'simile a questo:

Fondamentalmente possiamo avere un Windows Server che esegue fino a 15 (quindici) istanze di SQL Server su singoli indirizzi IP. Lo stesso vale per l'istanza dedicata di Reporting Services.

Regole del firewall

I diversi intervalli IP non sono attualmente configurati come zone, il che significa che dobbiamo configurare ciascuna regola del firewall in modo indipendente come regola IP-to-IP o IP-range-IP. Quando sono coinvolti due server, la sicurezza impone che debba sempre essere una regola da IP a IP. Ogni istanza di SQL Server avrà il proprio set di regole per i firewall coinvolti nelle comunicazioni, sia esso un collegamento da server a server o da client a server. La richiesta di una regola firewall comporta attualmente un periodo di attesa di 4-6 settimane. Ridurre la quantità di regole del firewall ridurrà la pressione sul team di sicurezza della rete.

Configurazione IP dell'istanza di SQL Server

La configurazione di un'istanza di SQL Server per il rilevamento solo su un IP e una porta dedicati viene eseguita modificando alcune impostazioni nell'utilità Gestione configurazione SQL Server. Il primo passo è avviare SQL Server Configuation Manager e nella sezione sinistra selezionare la configurazione di rete di SQL Server | Protocolli per InstanceName . Nel riquadro sinistro fare clic con il pulsante sinistro del mouse sul nome del protocollo TCP / IP e abilitare il protocollo. Quindi fare nuovamente clic con il pulsante sinistro del mouse sul protocollo e visualizzare la finestra Proprietà per TCP / IP .

Quindi assicurarsi che le seguenti impostazioni siano impostate nel registro Protocollo :

Enabled           : Yes
Listen All        : No

Nel registro degli indirizzi IP verificare le seguenti impostazioni per l'indirizzo IP in questione (ad es. Per il server Reporting Services in questo esempio sarebbe per 168.xxx.xxx.71)

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

Nota: è importante che l'impostazione per TCP Dynamic Ports sia vuota non solo a 0 (zero).

Ora hai un'istanza di SQL Server che raccoglierà le connessioni al database solo su 168.xxx.xxx.71 usando la porta 1433.

Riepilogo istanza di SQL Server

Il servizio SQL Server Browser non è in esecuzione e ogni singola istanza di SQL Server è configurata per utilizzare solo il proprio indirizzo IP sulla porta 1433. Data un'istanza di SQL Server denominata GENERAL, un server Windows con il nome host SQLSERVER01 e due indirizzi IP 162.xxx .xxx.50 (host) e 162.xxx.xxx.51 (istanza SQL) Concluderò con i seguenti elementi di configurazione:

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 non raccoglierà richieste per 162.xxx.xxx.50: 1433, poiché nessuna istanza di SQL Server è configurata per l'ascolto su questo indirizzo IP nell'utilità Gestione configurazione SQL Server. SQL Server raccoglierà solo le richieste per SQLSERVER01-i01 (sulla porta 1433) o 162.xxx.xxx.51,1433.

Riepilogo istanza di SQL Server Reporting Services

Il servizio SQL Server Browser non è in esecuzione e ogni singola istanza di SQL Server Reporting Services è configurata per utilizzare solo il proprio indirizzo IP sulla porta 1433. Data un'istanza di SQL Server Reporting Services denominata GENERAL, un server Windows con il nome host SQLSERVERRS01, un'applicazione sul nome SSRS APPL1e due indirizzi IP 168.xxx.xxx.70 (host) e 168.xxx.xxx.71 (istanza SQL) finirò con i seguenti elementi di configurazione:

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 non raccoglierà richieste per 168.xxx.xxx.70: 1433, poiché nessuna istanza di SQL Server è configurata per l'ascolto su questo indirizzo IP nell'utilità Gestione configurazione SQL Server. SQL Server raccoglierà solo richieste per SQLSERVER01-i01 (sulla porta 1433) o 162.xxx.xxx.71,1433.

SSRS raccoglierà le richieste per http: // sqlserverrs01-i01 / Reports_APPL1 o http: // sqlserverrs01 / Reports_APPL1 a causa della configurazione *: 80 nella configurazione di Reporting Services per le intestazioni host.

Spero di aver fornito informazioni sufficienti per chiunque sia disposto a trascorrere il proprio tempo a scrivere una risposta e non vedo l'ora di ricevere i tuoi dettagli tecnici e i tuoi collegamenti.

Scritto con StackEdit e successivamente modificato manualmente per essere compatibile con stackexchange.

Storia

Modifica 1 : versione iniziale
Modifica 2 : riformattata per essere leggibile. Spiegazione spiegata SF / DB verso il basso. Aggiunto nome host per Windows Server
Edit 3 : risolti indirizzi IP errati nell'elenco delle regole del firewall.
Modifica 4 : ha cambiato la parola hosting in esecuzione (è un ambiente non virtualizzato) in alcuni punti. Aggiunto indirizzo IP in una sola frase
Modifica 5 : aggiunto un elenco di articoli che ho già consultato e referenziato supporto
Modifica 6 : sezione Cronologia pulita

introduzione

Secondo i vari documenti che ho trovato durante la mia ricerca iniziale e i documenti forniti nei collegamenti e nelle discussioni, ho trovato una soluzione solida, affidabile e conforme.

RFC 3484

I confronti binari condotti più in basso e le regole applicate sono conformi alla RFC 3484, che a quanto pare è valido anche per gli indirizzi IPv4.

RFC 3484 afferma anche subito dopo la Regola 8

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.

Selezione dell'indirizzo IP di origine su un computer Windows multihomed

Ora non tutte le regole nella RFC 3484 si applicano agli indirizzi IPv4. L'articolo del blog di Microsoft Selezione dell'indirizzo IP di origine su un computer Windows multi-homed spiega quali regole si applicano.

C'è una piccola sezione appena sotto il comportamento di Windows Vista / Windows Server 2008 che recita:

Simile a XP quando un programma non specifica un IP di origine, lo stack fa riferimento all'indirizzo IP di destinazione e quindi esamina l'intera tabella di instradamento IP in modo che possa scegliere la migliore scheda di rete su cui inviare il pacchetto. Dopo aver scelto la scheda di rete, lo stack utilizza il processo di selezione dell'indirizzo definito in RFC 3484 e utilizza tale indirizzo IP come indirizzo IP di origine per i pacchetti in uscita.

Visto che ho solo una scheda NIC nell'istanza SQL / SSRS, la prima parte è discutibile. Windows Server sceglierà sempre l'unica scheda di rete disponibile.

Finora combinando RFC 3484 con il Blog di Microsoft risulta che entrambi gli indirizzi IP sono candidati validi per l'indirizzo IP di origine. La spiegazione segue più in basso nella risposta.

Antennista

Un articolo di Cable Guy I modelli di host forti e deboli di Cable Guy descrivono in dettaglio come funziona la selezione IP in un ambiente di invio e ricezione di host forti e in un ambiente di invio e ricezione di host deboli . Una buona lettura aggiuntiva, ma non fa più luce su come viene selezionato l'IP sorgente. L'articolo si riferisce alla già nota RFC 3484.

Spiegare l'inspiegabile

Per spiegare la soluzione, dobbiamo prima convertire gli indirizzi IP in questione nei loro equivalenti binari. Visto che non ho fornito gateway nella mia domanda, assumerò due valori.

Indirizzi IP di origine e notazione binaria

Ecco un elenco dei valori binari convertiti per gli indirizzi IP coinvolti.

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

Indirizzi IP di destinazione e notazione binaria

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

Esempio 1: IP gateway inferiore all'IP dell'istanza SQL / SSRS

In questo esempio suppongo che l'indirizzo IP del gateway sia inferiore all'indirizzo IP dell'istanza di SQL Server / SSRS, ovvero 168.001.001.002.

Se si confrontano entrambi gli indirizzi binari di Windows Server e l'istanza di SQL Server / SSRS, si ottiene quanto segue:

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)

Risultato Esempio 1

In questo esempio, entrambi gli indirizzi IP hanno la stessa quantità di bit di ordine superiore corrispondenti (o prefisso di corrispondenza più lungo). Fino ad ora il processo http.sys utilizzerà uno degli indirizzi IP per le comunicazioni in uscita.

Esempio 2: IP gateway superiore a IP istanza SQL / SSRS

In questo esempio suppongo che l'indirizzo IP del gateway sia superiore all'indirizzo IP dell'istanza di SQL Server / SSRS, ovvero 168.001.001.100.

Se si confrontano entrambi gli indirizzi binari di Windows Server e l'istanza di SQL Server / SSRS, si ottiene quanto segue:

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)

Risultato Esempio 2

Anche se l'indirizzo IP del gateway è ora maggiore dell'indirizzo IP del server Windows e dell'istanza SQL / SSRS, la quantità di bit di ordine elevato corrispondenti (o prefisso di corrispondenza più lungo) è sempre la stessa. Fino ad ora il processo http.sys utilizzerà uno degli indirizzi IP per le comunicazioni in uscita.

Sintesi dei risultati finora

Finora, è impossibile stabilire quale indirizzo IP verrà utilizzato dal processo http.sys per le comunicazioni in uscita in esecuzione sull'istanza SQL / SSRS (.71) sul server Windows (.70).

"Quando hai eliminato l'impossibile, tutto ciò che rimane, per quanto improbabile, deve essere la verità" - Sherlock Holmes

Ci sono situazioni in cui l'indirizzo IP di origine può essere sicuramente indicato / selezionato / definito con le conoscenze RFC e Microsoft sopra menzionate. Ma se gli indirizzi IP sono troppo vicini l'uno all'altro e vicino al gateway, allora è tutto per fortuna. O è?

Visto che sono nella posizione di rendere le regole (firewall) e Microsoft ha un ...

l'implementazione (che) ha altri mezzi per scegliere tra gli indirizzi di origine. Ad esempio, se l'implementazione in qualche modo sa quale indirizzo di origine comporterà le prestazioni di comunicazione "migliori".

... quindi tutto ciò che devo fare per determinare l'indirizzo IP del processo http.sys è creare una sola regola firewall con l'indirizzo IP desiderato.

Che succede

1. Definisco una regola firewall da 168.xxx.xxx.71 a 168.xxx.xxx.51: 1433
2. Il componente http.sys dell'istanza SQL / SSRS è conforme a RFC 3484 e seleziona l'IP di origine in base alle regole definite
3. L'indirizzo IP 168.xxx.xxx.71 (su NIC1) viene determinato come indirizzo IP di origine per raggiungere l'indirizzo IP 168.xxx.xxx.51 tramite la porta 1433 e viene quindi assegnato a tutti i pacchetti in uscita

Benefici

1. Non interferisco in alcun modo con l'implementazione di RFC 3484
2. Non mi gioco in alcun modo con percorsi o configurazioni ARP
3. Sono conforme a RFC 3484 e all'implementazione di Microsoft
4. Non sto hackerando alcuna impostazione del registro o configurazione di sistema
5. HO UNA REGOLA DI FIREWALL MENO

Verifica

Devo ancora rimuovere l'indirizzo IP dalle regole del firewall, ma sono sicuro che funzionerà come progettato / definito. Seguirà un riepilogo.

Storia

Modifica 1 Messaggio iniziale
Modifica 2 Risposta pulita, aggiunta sezione Cronologia

SSRS supporta diverse origini dati standard, nonché altre origini dati .NET:

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

Supponendo che si stia utilizzando il client nativo SQL per l'origine dati, non è possibile specificare un indirizzo IP di origine:

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

Pertanto è ovvio che il client utilizzerà IPADDR_ANY durante il metodo Bind () durante l'impostazione della connessione di rete. Questo lascia Windows a prendere la decisione.

La selezione dell'indirizzo di Windows 2008 e versioni successive si basa sul numero più alto di bit corrispondenti con l'hop successivo, il che significa che la risposta dipende dal gateway predefinito (o da qualsiasi percorso specifico definito).

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

Non ho visto alcuna menzione di percorsi o gateway nel tuo diagramma, quindi per quanto ho potuto ottenere.

In bocca al lupo!