Tl; Dr

Çok örnekli bir SQL Server'da (Windows Server'daki her SQL Server örneğinin kendi IP adresi vardır) ayrılmış bir IP adresi ve bağlantı noktası (162.xxx.xxx.51: 1433) bulunan bir SQL Server örneği (SQLSERVER01-i01) var ) tek bir Windows sunucusunda (SQLSERVER01 / 162.xxx.xxx.50) çalışır.

Ayrıca, kendi IP adresi (168SxxVER.xxx.71: 1433) olan ve kendi IP adresiyle (168) farklı bir Windows sunucusunda (SQLSERVERRS01) çalışan özel bir Reporting Services örneğim (SQLSERVERRS01-i01) var. .xxx.xxx.70).

Özel Reporting Services sunucusunda, APPL1üzerinden http://SQLSERVERRS01-i01:80/Reports_APPL1veya aracılığıyla erişilebilen bir uygulama vardır http://SQLSERVERRS01:80/Reports_APPL1.

SSRS *:80, ana bilgisayar üstbilgileri için Raporlama Hizmetleri Yapılandırması'ndaki yapılandırma nedeniyle her iki isteği de alır .

Her IP aralığı arasında birden fazla güvenlik duvarımız var, yani her IP-IP veya IPrange-IP bağlantısı için belirli bir kural için başvurmamız gerekiyor. Ancak, iki sunucu söz konusu olduğunda, güvenlik, güvenlik duvarında her zaman IP'den IP'ye bir kural olması gerektiğini belirler.

Soru

(ekran görüntüsüne göre daha aşağıda)

Reporting Services sunucusu veri almak için SQL Server örneğine (162.xxx.xxx.51 üzerinde) bağlandığında, her zaman Windows sunucusunun temel IP adresiyle (168.xxx.xxx.70 / tercih edilir) bir bağlantı kurar mı? ) SSRS'nin üzerinde çalıştığı veya SQL Server Reporting Services örneğinin (168.xxx.xxx.71) IP adresini (bazen) kullanacak mı?

Bu, IP-IP yaklaşımı kullanılarak güvenlik duvarı kuralının yapılandırılmasıyla ilgilidir. Ya 1433 numaralı bağlantı noktası üzerinden 168.xxx.xxx.71 - 162.xxx.xxx.51 bağlantısını veya üzerinden 168.xxx.xxx.70 - 162.xxx.xxx.51 bağlantısını tanımlayan bir kurala başvurmam gerekecek bağlantı noktası 1433.

Şu anda her iki güvenlik duvarı kuralına da başvururum.

Bonus soru

Reporting Services sunucusunu özel bir IP adresiyle iletişim kuracak şekilde yapılandırabilir miyim? Bu durumda 168.xxx.xxx.71 adresi ile.

Aradığım cevaplar

Güvenlik duvarı yapılandırmasının nasıl optimize edileceği veya ağlarımız için bir imar kavramının nasıl uygulanacağı konusunda tavsiye istemiyorum. (Zaten boru hattında). Ayrıca, aynı sunucuda SQL Server ve SSRS'ye sahip olmanın sorunlarımı çözeceğini öne süren geri bildirimle ilgilenmiyorum. Bunu biliyorum ve memnuniyetle yapardım ama SSRS bileşenleri ile birlikte çalışması gereken üçüncü taraf yazılımlar için.

İşe yarıyor

SSRS ve SQL Server örneği arasında her iki güvenlik duvarı kuralını da uygularsam sahip olduğum yapılandırma çalışır.

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

Bir güvenlik duvarı kuralıyla güvenli bir şekilde azaltmak ve her şeyin hala çalışmasını sağlamak istiyorum. (Bkz ayrıca aşağı ekran görüntüsü)
Düzenleme: Şimdiye kadar okudum makaleler sadece ikinci kurala gereksinim düşündüren, ama garantisi yoktur.

Daha önce danıştığım makaleler

1. SQL Server Yükleme
   Tabanı makalesi için Güvenlikle İlgili Konular .

2. Windows Güvenlik Duvarı'nı SQL Server Erişimine İzin Verecek Şekilde Yapılandırma
   Bu makale, SQL Server için güvenlik duvarı yapılandırmasına ilişkin diğer tüm makalelere işaret etmektedir.

3. Veritabanı Altyapısı Erişimi için Windows Güvenlik Duvarı Yapılandırma
   IP adresi sözcüğü kullanılmaz.

4. Güvenlik Sunucusunu Rapor Sunucusu Erişimi için Yapılandırma
   Bu makale belirtildiği gibi oldukça ilginçti:

   Harici bilgisayarlarda SQL Server ilişkisel veritabanlarına erişiyorsanız veya rapor sunucusu veritabanı harici bir SQL Server örneğindeyse, harici bilgisayarda 1433 ve 1434 numaralı bağlantı noktalarını açmanız gerekir.

   ... ama yine de IP yapılandırması / ayarlar / varsayılanlar hakkında tek bir kelime bile yok.

5. Çok Homed Windows Bilgisayarda Kaynak IP adresi seçimi

6. Windows Server 2008 ve Windows Vista'da kaynak IP adresi seçimi işlevselliği, Windows'un önceki sürümlerinde karşılık gelen işlevsellikten farklıdır

5. ve 6. Maddeler bana James (dba.se) tarafından verilmiştir. Şu anda en uygun cevaplar gibi görünüyorlar. Bununla birlikte, bir makalenin birden fazla NIC kullanımından bahsetmesine biraz şüpheliyim, oysa kendisine atanan birden fazla IP'ye sahip tek bir NIC var. Tom (dba.se) aynı zamanda tavsiye ve genel yorumlar da yaptı.

Neden burada ve dba.stackexchange.com'da değil

Sorunun karmaşık yapısı nedeniyle ilk başta bu soruyu serverfault.com'da yayınlamakta isteksizdim. Sorunun her ikisi de SQL Server'a özgü olma eğilimindedir, aynı zamanda Windows Server'a özgü olma eğilimindedir. Sonunda buraya göndermeye karar verdim, çünkü bir Windows Server IP işleme şeyidir (daha iyi kelimelerin kaybı için).

Bir moderatör dba.stackexchange.com'da daha iyi bir yanıt alacağımı düşünüyorsa, lütfen soruyu oraya taşıyın.

Uzun Açıklama

Ortamımızda birden fazla SQL Server örneği ve birden fazla IP ayarı barındıran Windows sunucularımız var. Karmaşık güvenlik duvarı yapılandırmaları, özel SQL Server Raporlama Servisleri (SSRS) sunucuları ekliyoruz ve buna benzer bir ortam buluyoruz:

Temel olarak, tek bir IP adresinde en fazla 15 (on beş) SQL Server örneği çalıştıran bir Windows Sunucumuz olabilir. Aynısı, özel Raporlama Servisleri örneği için de geçerlidir.

Güvenlik Duvarı Kuralları

Farklı IP aralıkları şu anda bölge olarak yapılandırılmamıştır, yani her güvenlik duvarı kuralını bağımsız olarak IP-IP veya IPrange-IP kuralı olarak yapılandırmamız gerekir. İki sunucu söz konusu olduğunda, güvenlik her zaman IP-IP kuralı olması gerektiğini belirtir. Her SQL Server örneğinin, bu sunucudan sunucuya veya istemciden sunucuya bağlantı olması gibi iletişimde yer alan güvenlik duvarları için kendi kuralları vardır. Güvenlik duvarı kuralı başvurusu şu anda dört ila altı haftalık bir bekleme süresine tabidir. Güvenlik duvarı kurallarının miktarının azaltılması, ağ güvenlik ekibindeki baskı miktarını azaltacaktır.

SQL Server Örneği IP Yapılandırması

Bir SQL Server örneğini yalnızca özel bir IP ve bağlantı noktasında alacak şekilde yapılandırmak, SQL Server Configuration Manager yardımcı programındaki bazı ayarları değiştirerek gerçekleştirilir. İlk adım SQL Server Yapılandırma Yöneticisi'ni başlatmak ve sol bölümde SQL Server Ağ Yapılandırması | ÖrnekAdı için Protokoller . Sol bölmede TCP / IP Protokol Adı'nı sol tıklatın ve Protokolü etkinleştirin . Ardından protokolü tekrar sol tıklayın ve TCP / IP Özellikleri penceresini açın.

Ardından Protokol kaydında aşağıdaki ayarların yapıldığından emin olun :

Enabled           : Yes
Listen All        : No

In IP Adresleri (o 168.xxx.xxx.71 olurdu bu örnekte Raporlama Hizmetleri sunucusu için örneğin) Söz konusu IP adresi için aşağıdaki ayarları kontrol kayıt

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

Not: TCP Dinamik Bağlantı Noktaları ayarının yalnızca 0 (sıfır) değil boş olması önemlidir .

Artık veritabanı bağlantılarını 1433 numaralı bağlantı noktasını kullanarak 168.xxx.xxx.71 üzerinde toplayacak bir SQL Server örneğine sahipsiniz.

SQL Server Örnek Özeti

SQL Server Tarayıcı hizmeti çalışmıyor ve her bir SQL Server örneği, 1433 numaralı bağlantı noktasında yalnızca kendi IP adresini kullanacak şekilde yapılandırılmış. GENERAL adlı bir SQL Server örneği, ana bilgisayar adı SQLSERVER01 ve iki IP adresi 162.xxx verildiğinde .xxx.50 (ana bilgisayar) ve 162.xxx.xxx.51 (SQL Örneği) Aşağıdaki yapılandırma öğeleriyle karşılaşacağım:

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 162.xxx.xxx.50: 1433 için SQL Server Configuration Manager yardımcı programında bu IP adresini dinleyecek şekilde yapılandırılmadığından SQL Server isteklerini almayacaktır. SQL Server yalnızca SQLSERVER01-i01 (bağlantı noktası 1433'te) veya 162.xxx.xxx.51,1433 için istekleri alır.

SQL Server Raporlama Servisleri Örneği Özeti

SQL Server Tarayıcı hizmeti çalışmıyor ve her bir SQL Server Raporlama Hizmetleri örneği, 1433 numaralı bağlantı noktasında yalnızca kendi IP adresini kullanacak şekilde yapılandırıldı. SQLSERVERRS01 ana bilgisayar adına sahip bir Windows sunucusu olan GENERAL adlı bir SQL Server Raporlama Hizmetleri örneği verildi SSRS adında APPL1ve iki IP adresi 168.xxx.xxx.70 (ana bilgisayar) ve 168.xxx.xxx.71 (SQL Örneği) üzerinde aşağıdaki yapılandırma öğeleri ile karşılaşacağım:

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 Yapılandırma Yöneticisi yardımcı programında bu IP adresini dinleyecek şekilde yapılandırılmadığından, SQL Server 168.xxx.xxx.70: 1433 için istekleri almayacaktır. SQL Server yalnızca SQLSERVER01-i01 (bağlantı noktası 1433'te) veya 162.xxx.xxx.71,1433 için istekleri alır.

SSRS , ana bilgisayar üstbilgileri için Reporting Services Yapılandırmasında *: 80 yapılandırması nedeniyle http: // sqlserverrs01-i01 / Reports_APPL1 veya http: // sqlserverrs01 / Reports_APPL1 için istekleri alır.

Umarım zamanını bir cevap yazarak geçirmek isteyen herkes için yeterli bilgi sağladım ve teknik detaylarınızı ve bağlantılarınızı dört gözle bekliyorum.

StackEdit ile yazılmıştır ve daha sonra stackexchange uyumlu olacak şekilde manuel olarak değiştirilmiştir.

Tarih

Düzenleme 1 : İlk Sürüm
Düzenleme 2 : Okunabilirlik için yeniden biçimlendirildi. SF / DB açıklaması kaldırıldı. Windows Server
Düzenleme 3 için ana bilgisayar adı eklendi : Güvenlik duvarı kuralları listesindeki yanlış IP adresleri düzeltildi.
Edit 4 : Hosting kelimesini bazı yerlerde çalışacak şekilde değiştirdi (sanallaştırılmamış bir ortam). Bir kez cümleye IP adresi eklendi
Edit 5 : Daha önce danıştığım ve desteklediğim makalelerin bir listesi eklendi
Edit 6 : Cleaned History

Giriş

İlk araştırmam sırasında bulduğum çeşitli belgelere ve bağlantılarda ve tartışmalarda sunulan belgelere göre sağlam, güvenilir, uyumlu bir çözüm buldum.

RFC 3484

Daha aşağıda yapılan ikili karşılaştırmalar ve uygulanan kurallar , görünüşte IPv4 adresleri için de geçerli olan RFC 3484'e göredir .

RFC 3484 ayrıca Kural 8'den hemen sonra

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.

Çok Homed Windows Bilgisayarda Kaynak IP adresi seçimi

Artık RFC 3484'teki tüm kurallar IPv4 adresleri için geçerli değildir. Çok Homed Windows Bilgisayardaki Kaynak IP adresi seçimi Microsoft Blog makalesinde hangi kuralların geçerli olduğu açıklanmaktadır.

Windows Vista / Windows Server 2008 Davranışının hemen altında küçük bir bölüm vardır :

Bir program kaynak IP belirtmediğinde XP'ye benzer şekilde, yığın hedef IP adresine başvurur ve ardından paketin gönderileceği en iyi ağ bağdaştırıcısını seçebilmesi için tüm IP yol tablosunu inceler. Ağ bağdaştırıcısı seçildikten sonra, yığın, RFC 3484'te tanımlanan adres seçim işlemini kullanır ve bu IP adresini, giden paketler için kaynak IP adresi olarak kullanır.

SQL / SSRS örneğinde sadece bir NIC var gibi görüyorum ilk bölüm tartışma. Windows Server her zaman kullanılabilir olan tek NIC'yi seçer.

Şimdiye kadar RFC 3484'ü Microsoft Blog ile birleştirmek, her iki IP adresinin de kaynak IP adresi için geçerli adaylar olmasını sağlar. Açıklama, cevabın ilerleyen kısımlarındadır.

Kablo Adamı

Cable Guy'dan bir makale Cable Guy Güçlü ve Zayıf Ana Makine Modelleri , IP seçiminin Güçlü Ana Makine Gönderme ve Alma ortamında ve Zayıf Ana Makine Gönderme ve Alma ortamında nasıl çalıştığı hakkında daha fazla ayrıntıya girer . İyi bir ek okuma, ancak kaynak IP'nin nasıl seçildiğine artık ışık tutmaz. Makale, halihazırda bilinen RFC 3484 ile ilgilidir.

Açıklanamayan açıklaması

Çözümü açıklamak için öncelikle söz konusu IP adreslerini ikili eşdeğerlerine dönüştürmeliyiz. Sorumda ağ geçidi sağlamadığımı görünce iki değer alacağım.

Kaynak IP Adresleri ve İkili Gösterim

İlgili IP adresleri için dönüştürülmüş ikili değerlerin listesi.

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

Hedef IP Adresleri ve İkili Gösterim

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

Örnek 1: Ağ Geçidi IP'si SQL / SSRS Örnek IP'sinden daha düşük

Bu örnekte, ağ geçidinin IP adresinin SQL Server / SSRS örneğinin, yani 168.001.001.002 IP adresinden daha düşük olduğunu varsayacağım.

Windows Server ve SQL Server / SSRS örneğinin her iki ikili adresini karşılaştırırsanız, aşağıdakilere sahip olursunuz:

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)

Sonuç Örneği 1

Bu örnekte her iki IP adresi de aynı miktarda eşleşen yüksek dereceli bitlere (veya en uzun eşleşen ön eke) sahiptir. Şimdiye kadar http.sys işlemi giden iletişim için IP adreslerinden birini kullanacaktır.

Örnek 2: Ağ Geçidi IP'si SQL / SSRS Örnek IP'den daha yüksek

Bu örnekte, ağ geçidinin IP adresinin SQL Server / SSRS örneğinin, yani 168.001.001.100 IP adresinden daha yüksek olduğunu varsayacağım.

Windows Server ve SQL Server / SSRS örneğinin her iki ikili adresini karşılaştırırsanız, aşağıdakilere sahip olursunuz:

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)

Sonuç Örneği 2

Ağ geçidinin IP adresi artık Windows sunucusunun IP adresinden ve SQL / SSRS örneğinden daha yüksek olsa da, eşleşen yüksek dereceli bitlerin (veya en uzun eşleşen önekin) miktarı hala aynıdır. Şimdiye kadar http.sys işlemi giden iletişim için IP adreslerinden birini kullanacaktır.

Şimdiye Kadar Bulguların Özeti

Şimdiye kadar, http.sys işleminin hangi IP adresinin Windows sunucusundaki (.70) SQL / SSRS örneğinde (.71) çalışan giden iletişim için kullanılacağını söylemek mümkün değildir.

"İmkansızı ortadan kaldırdığınızda, ne kadar imkansız olursa olsun, gerçek ne olmalı" - Sherlock Holmes

Kaynak IP adresinin yukarıda belirtilen RFC ve Microsoft bilgisi ile kesin olarak işaretlenebileceği / seçilebileceği / tanımlanabileceği durumlar vardır. Ancak IP adresleri birbirine ve ağ geçidine çok yakınsa, hepsi şansa bağlıdır. Yoksa öyle mi?

Ben (güvenlik duvarı) kuralları yapma pozisyonunda olduğumu ve Microsoft bir ...

Gerçekleştirmenin (bu) kaynak adresler arasından seçim yapmak için başka yolları vardır. Örneğin, uygulama bir şekilde hangi kaynak adresinin "en iyi" iletişim performansıyla sonuçlanacağını biliyorsa.

... sonra http.sys işleminin IP adresini belirlemek için tek yapmam gereken , istenen IP adresine sahip tek bir güvenlik duvarı kuralı oluşturmaktır.

Ne oluyor

1. 168.xxx.xxx.71 ile 168.xxx.xxx.51: 1433 arasında bir güvenlik duvarı kuralı tanımlarım
2. SQL / SSRS örneğinin http.sys bileşeni RFC 3484 ile uyumludur ve tanımlı kurallara göre kaynak IP'sini seçer
3. IP adresi 168.xxx.xxx.71 (NIC1'de), 1433 numaralı bağlantı noktası üzerinden 168.xxx.xxx.51 IP adresine ulaşmak için kaynak IP adresi olarak belirlenir ve böylece tüm giden paketlere atanır

Yararları

1. Hiçbir şekilde RFC 3484'ün uygulanmasına müdahale etmiyorum
2. Hiçbir şekilde rota veya ARP yapılandırmalarıyla hokkabazlık yapmıyorum
3. RFC 3484 ve Microsoft'un uygulamasına uyuyorum
4. Herhangi bir kayıt defteri ayarını veya sistem yapılandırmasını hacklemiyorum
5. BİR GÜVENLİK DUVARI DAHA AZ

Doğrulama

IP adresinin güvenlik duvarı kurallarından kaldırılmamış olmasına rağmen, tasarlandığı / tanımlandığı gibi çalışacağından eminim. Bir özet gelecektir.

Tarih

Düzenle 1 İlk Mesaj
Düzenle 2 Temizlenen yanıt, Geçmiş bölümü eklendi

SSRS, çeşitli standart veri kaynaklarını ve diğer .NET veri kaynaklarını destekler:

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

Veri kaynağı için SQL yerel istemcisini kullandığınızı varsayarsak, bir kaynak IP adresi belirtme seçeneğiniz yoktur:

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

Bu nedenle, istemcinin ağ bağlantısını kurarken Bind () yöntemi sırasında IPADDR_ANY kullanması gerekir. Bu karar vermek için Windows bırakır.

Windows 2008 ve üstü adres seçimi, bir sonraki sekme ile en fazla eşleşen bit sayısına dayanır; bu, yanıtın varsayılan ağ geçidinize (veya tanımladığınız belirli rotalara) bağlı olduğu anlamına gelir.

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

Diyagramınızda rotalardan veya geçitlerden bahsetmedim, bu yüzden alabildiğim kadarıyla.

İyi şanslar!