SQL सर्वर रिपोर्टिंग सेवा (SSRS) मल्टी-इंस्टेंस सर्वर पर आईपी हैंडलिंग


9

Tl डॉ

मेरे पास एक समर्पित आईपी पते और पोर्ट (162.xxx.xxx.51: 1433) के साथ एक SQL सर्वर उदाहरण (SQLSERVER01-i01) एक बहु-उदाहरण SQL सर्वर पर है (Windows सर्वर पर प्रत्येक SQL सर्वर आवृत्ति का अपना स्वयं का पता है) ) जो सभी एक विंडोज सर्वर (SQLSERVER01 / 162.xxx.xxx.50) पर चल रहे हैं।

मेरे पास स्वयं के आईपी पते और पोर्ट (168.xxx.xxx.71: 1433) के साथ एक समर्पित रिपोर्टिंग सेवा उदाहरण (SQLSERVERRS01-i01) है, जो अपने स्वयं के आईपी पते (168) के साथ एक अलग विंडोज सर्वर (SQLSERVERRS01) पर चल रहा है। .xxx.xxx.70)।

समर्पित रिपोर्टिंग सेवा सर्वर में एक एप्लिकेशन है APPL1जिसे http://SQLSERVERRS01-i01:80/Reports_APPL1या तो माध्यम से या उसके माध्यम से पहुँचा जा सकता है http://SQLSERVERRS01:80/Reports_APPL1

*:80होस्ट हेडर के लिए रिपोर्टिंग सेवा कॉन्फ़िगरेशन में कॉन्फ़िगरेशन के कारण SSRS दोनों अनुरोधों को उठाएगा।

हमारे पास प्रत्येक आईपी रेंज के बीच कई फायरवॉल हैं, जिसका अर्थ है कि हमें प्रत्येक आईपी-टू-आईपी या आईपी-अरेंज-टू-आईपी कनेक्शन के लिए एक विशिष्ट नियम के लिए आवेदन करना होगा। हालाँकि जब दो सर्वर शामिल होते हैं, तो सुरक्षा तय करती है कि फ़ायरवॉल में हमेशा आईपी-टू-आईपी नियम होना चाहिए।

सवाल

(नीचे स्क्रीन शॉट के आधार पर)

जब रिपोर्टिंग सेवा सर्वर डेटा को पुनः प्राप्त करने के लिए SQL सर्वर आवृत्ति (162.xxx.xxx.51 पर) से कनेक्ट होता है, तो क्या यह हमेशा विंडोज़ सर्वर (168.xxx.xxx.70 / पसंदीदा) के अंतर्निहित आईपी पते के साथ एक कनेक्शन का निर्माण करेगा। ) कि SSRS चल रहा है, या यह (कभी-कभी) SQL सर्वर रिपोर्टिंग सेवा उदाहरण (168.xxx.xxx.71) के आईपी पते का उपयोग करेगा?

यह आईपी-टू-आईपी दृष्टिकोण का उपयोग करके फ़ायरवॉल नियम के कॉन्फ़िगरेशन के लिए प्रासंगिक है। मुझे या तो एक नियम के लिए आवेदन करना होगा जो 168.xxx.xxx.71 को 162.xxx.xxx.51 कनेक्शन पर पोर्ट 1433 या 168.xxx.xxx.70 के माध्यम से 162.xxx.xxx11 कनेक्शन के माध्यम से परिभाषित करता है। पोर्ट 1433।

वर्तमान में मैं दोनों फ़ायरवॉल नियमों के लिए आवेदन करूंगा।

बोनस प्रश्न

क्या मैं समर्पित IP पते के साथ संचार करने के लिए रिपोर्टिंग सेवा सर्वर को कॉन्फ़िगर कर सकता हूं? इस मामले में 168.xxx.xxx.71 पते के साथ।

उत्तर मैं नहीं ढूंढ रहा हूं

मैं सलाह नहीं दे रहा हूं कि फ़ायरवॉल कॉन्फ़िगरेशन को कैसे अनुकूलित किया जाए या हमारे नेटवर्क के लिए ज़ोनिंग अवधारणा को कैसे लागू किया जाए। (यह पहले से ही पाइपलाइन में है)। इसके अतिरिक्त, मुझे यह सुझाव देने में कोई दिलचस्पी नहीं है कि एक ही सर्वर पर SQL सर्वर और SSRS होने से मेरे मुद्दों का समाधान हो जाएगा। मुझे पता है कि और ख़ुशी से ऐसा करेंगे लेकिन SSRS घटकों के साथ चलने के लिए आवश्यक तृतीय-पक्ष सॉफ़्टवेयर के लिए।

यह काम करता हैं

यदि मेरे पास SSRS और SQL सर्वर आवृत्ति के बीच फ़ायरवॉल नियम लागू होता है, तो कॉन्फ़िगरेशन मेरे पास काम करता है।

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

मैं एक फ़ायरवॉल नियम को सुरक्षित रूप से कम करना चाहता हूं और यह सुनिश्चित करता हूं कि सब कुछ अभी भी काम करेगा। (स्क्रीनशॉट को और नीचे देखें)
संपादित करें: मैंने अब तक जो लेख पढ़े हैं, वे सुझाव दे रहे हैं कि मुझे केवल दूसरे नियम की आवश्यकता है, लेकिन इसकी कोई गारंटी नहीं है।

लेख जिन्हें मैंने पहले ही परामर्श दिया है

  1. SQL सर्वर स्थापना
    बेस आलेख के लिए सुरक्षा विचार

  2. SQL सर्वर को अनुमति देने के लिए Windows फ़ायरवॉल कॉन्फ़िगर करें
    यह आलेख SQL सर्वर के लिए फ़ायरवॉल कॉन्फ़िगरेशन के बारे में अन्य सभी लेखों को इंगित करता है।

  3. डेटाबेस इंजन एक्सेस के लिए विंडोज फ़ायरवॉल कॉन्फ़िगर करें
    आईपी ​​उपयोग किए गए पते का कोई शब्द नहीं।

  4. रिपोर्ट सर्वर पहुँच के लिए फ़ायरवॉल कॉन्फ़िगर करें
    यह आलेख बहुत ही रोचक था क्योंकि यह नोट किया गया था:

    यदि आप बाहरी कंप्यूटर पर SQL सर्वर रिलेशनल डेटाबेस तक पहुँच रहे हैं, या यदि रिपोर्ट सर्वर डेटाबेस बाहरी SQL सर्वर उदाहरण पर है, तो आपको बाहरी कंप्यूटर पर पोर्ट 1433 और 1434 खोलना होगा।

    ... लेकिन अभी भी आईपी कॉन्फ़िगरेशन / सेटिंग्स / चूक के बारे में एक शब्द नहीं है।

  5. मल्टी-विंडोज विंडोज कंप्यूटर पर स्रोत आईपी पता चयन

  6. Windows Server 2008 और Windows Vista में स्रोत IP पता चयन के लिए कार्यक्षमता Windows के पुराने संस्करणों में संबंधित कार्यक्षमता से भिन्न होती है

लेख 5 और 6 कृपया मुझे जेम्स (dba.se) द्वारा प्रदान किए गए । वे वर्तमान में सबसे उपयुक्त उत्तर प्रतीत होते हैं। मैं हालांकि थोड़ा सशंकित हूं कि एक लेख में कई एनआईसी के उपयोग का उल्लेख है जबकि मेरे पास केवल एक एनआईसी है जिसमें कई आईपी को सौंपा गया है। टॉम (dba.se) ने सलाह और सामान्य टिप्पणियों के साथ भी चुटकी ली है।

यहाँ क्यों और dba.stackexchange.com में नहीं

प्रश्न की जटिल प्रकृति के कारण मैं serverfault.com में इस प्रश्न को पोस्ट करने के लिए सबसे पहले अनिच्छुक था। प्रश्न में SQL सर्वर विशिष्ट होने के लिए दोनों की प्रवृत्ति है, लेकिन Windows सर्वर विशिष्ट होने के लिए भी। आखिरकार मैंने इसे यहां पोस्ट करने का फैसला किया, क्योंकि मुझे लगता है कि यह एक विंडोज सर्वर आईपी हैंडलिंग चीज़ है (बेहतर शब्दों के नुकसान के लिए)।

यदि कोई मॉडरेटर यह सोचता है कि मुझे dba.stackexchange.com में बेहतर प्रतिक्रिया मिलेगी तो कृपया इस प्रश्न को वहाँ ले जाएँ।

लंबी व्याख्या

हमारे वातावरण में हमारे पास कई SQL सर्वर इंस्टेंस और कई IP सेटिंग्स की मेजबानी करने वाले विंडोज सर्वर हैं। हम जटिल फ़ायरवॉल कॉन्फ़िगरेशन जोड़ते हैं, समर्पित SQL सर्वर रिपोर्टिंग सेवा (SSRS) सर्वर और एक वातावरण के साथ आते हैं जो इस तरह से दिखता है:

पर्यावरण अवलोकन

मूल रूप से हम एक विंडोज सर्वर को 15 (पंद्रह) SQL सर्वर इंस्टेंसेस व्यक्तिगत IP पते पर चला सकते हैं। वही समर्पित रिपोर्टिंग सेवा उदाहरण के लिए मान्य है।

फ़ायरवॉल नियम

अलग-अलग आईपी रेंज वर्तमान में ज़ोन के रूप में कॉन्फ़िगर नहीं किए गए हैं, जिसका अर्थ है कि हमें प्रत्येक फ़ायरवॉल नियम को स्वतंत्र रूप से आईपी-टू-आईपी या आईपी अरेंज-टू-आईपी नियम के रूप में कॉन्फ़िगर करना होगा। जब दो सर्वर शामिल होते हैं, तो सुरक्षा तय करती है कि इसे हमेशा आईपी-टू-आईपी नियम होना चाहिए। प्रत्येक SQL सर्वर आवृत्ति में संचार में शामिल फ़ायरवॉल के लिए नियमों का अपना सेट होगा, यह एक सर्वर-से-सर्वर या क्लाइंट-टू-सर्वर लिंक हो। एक फ़ायरवॉल नियम के लिए वर्तमान में चार से छह सप्ताह की प्रतीक्षा अवधि होती है। फ़ायरवॉल नियमों की मात्रा कम करने से नेटवर्क सुरक्षा टीम पर दबाव की मात्रा कम हो जाएगी।

SQL सर्वर इंस्टेंस IP कॉन्फ़िगरेशन

SQL सर्वर आवृत्ति को केवल एक समर्पित IP पर लेने के लिए कॉन्फ़िगर करना और SQL सर्वर कॉन्फ़िगरेशन प्रबंधक उपयोगिता में कुछ सेटिंग्स को संशोधित करके पोर्ट का प्रदर्शन किया जाता है। SQL सर्वर कॉन्फ़िगरेशन प्रबंधक को प्रारंभ करने के लिए पहला चरण है और बाएँ अनुभाग में SQL सर्वर नेटवर्क कॉन्फ़िगरेशन का चयन करें InstanceName के लिए प्रोटोकॉल । बाएँ फलक में TCP / IP प्रोटोकॉल नाम पर क्लिक करें और प्रोटोकॉल को सक्षम करें । फिर प्रोटोकॉल पर फिर से क्लिक करें और गुण टीसीपी / आईपी विंडो के लिए लाएं ।

फिर सुनिश्चित करें कि निम्नलिखित सेटिंग्स प्रोटोकॉल रजिस्टर में सेट की गई हैं :

Enabled           : Yes
Listen All        : No

में आईपी पतों रजिस्टर (इस उदाहरण में रिपोर्टिंग सेवा सर्वर यह 168.xxx.xxx.71 के लिए किया जाएगा के लिए उदाहरण के लिए) विचाराधीन आईपी पते के लिए निम्नलिखित सेटिंग्स की जाँच करें

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

नोट: यह महत्वपूर्ण है कि टीसीपी डायनेमिक पोर्ट के लिए सेटिंग खाली है न कि केवल 0 (शून्य)।

अब आपके पास SQL ​​सर्वर इंस्टेंस है जो केवल पोर्ट 1433 का उपयोग करके 168.xxx.xxx.71 पर डेटाबेस कनेक्शन पिक करेगा।

SQL सर्वर इंस्टेंस सारांश

SQL सर्वर ब्राउज़र सेवा नहीं चल रही है और प्रत्येक अलग-अलग SQL सर्वर इंस्टेंस को पोर्ट 1433 पर केवल अपने आईपी पते का उपयोग करने के लिए कॉन्फ़िगर किया गया है। एक सामान्य नाम से SQL सर्वर इंस्टेंस को देखते हुए, होस्ट नाम SQLSERVER01 और दो IP पते के साथ एक विंडोज़ सर्वर 162.xxx .xxx.50 (होस्ट) और 162.xxx.xxx.51 (SQL इंस्टेंस) मैं निम्नलिखित विन्यास वस्तुओं के साथ समाप्त होगा:

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 सर्वर 162.xxx.xxx.50: 1433 के लिए अनुरोध नहीं उठाएगा, क्योंकि SQL सर्वर कॉन्फ़िगरेशन प्रबंधक उपयोगिता में इस आईपी पते पर सुनने के लिए कोई SQL सर्वर आवृत्ति कॉन्फ़िगर नहीं है। SQL सर्वर केवल SQLSERVER01-i01 (पोर्ट 1433 पर) या 162.xxx.xxx.51,1433 के लिए अनुरोध उठाएगा।

SQL सर्वर रिपोर्टिंग सेवा इंस्टेंस सारांश

SQL सर्वर ब्राउज़र सेवा नहीं चल रही है और प्रत्येक व्यक्ति SQL सर्वर रिपोर्टिंग सेवा का उदाहरण केवल पोर्ट 1433 पर अपने स्वयं के IP पते का उपयोग करने के लिए कॉन्फ़िगर किया गया है। एक SQL सर्वर रिपोर्टिंग सेवा के उदाहरण को दिया जाता है, जिसे GENERAL कहा जाता है, होस्ट नाम SQLSERVERRIT01 के साथ एक Windows सर्वर नामित SSRS पर APPL1और दो IP पते 168.xxx.xxx.70 (होस्ट) और 168.xxx.xxx.71 (SQL इंस्टेंस) मैं निम्नलिखित विन्यास वस्तुओं के साथ समाप्त होगा:

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 सर्वर 168.xxx.xxx.70: 1433 के लिए अनुरोध नहीं उठाएगा, क्योंकि SQL सर्वर कॉन्फ़िगरेशन प्रबंधक उपयोगिता में इस आईपी पते पर सुनने के लिए कोई SQL सर्वर आवृत्ति कॉन्फ़िगर नहीं है। SQL सर्वर केवल SQLSERVER01-i01 (पोर्ट 1433 पर) या 162.xxx.xxx.71,1433 के लिए अनुरोध उठाएगा।

SSRS http: // sqlserverrs01-i01 / Report_APPL1 या http: // sqlserverrs01 / Report_APPL1 के लिए अनुरोधों को उठाएगा क्योंकि *: होस्टर्स के हेडर के लिए रिपोर्टिंग सेवा कॉन्फ़िगरेशन में 80configuration।

मुझे आशा है कि मैंने उत्तर लिखने में अपना समय बिताने के इच्छुक किसी भी व्यक्ति के लिए पर्याप्त जानकारी की आपूर्ति की है और मैं आपके तकनीकी विवरण और लिंक का इंतजार कर रहा हूं।

StackEdit के साथ लिखा गया और बाद में मैन्युअल रूप से संशोधित किया गया जिसे स्टेक्सएक्सचेंज संगत किया गया।

इतिहास

संपादित करें 1 : आरंभिक रिलीज
संपादित करें 2 : पठनीयता के लिए सुधारित। एसएफ / डीबी नीचे स्पष्टीकरण ले जाया गया। विंडोज सर्वर
एडिट 3 के लिए होस्ट नाम जोड़ा गया : फ़ायरवॉल नियमों की सूची में फिक्स्ड गलत आईपी पते।
संपादन 4 : कुछ जगहों पर होस्टिंग शब्द को रनिंग में बदल दिया (यह एक गैर-आभासी वातावरण है)। एक बार वाक्य में IP पता जोड़ा गया
5 संपादित करें : उन लेखों की एक सूची जोड़ी जो मैंने पहले ही परामर्श और संदर्भित समर्थन
संपादित कर चुके हैं 6 संपादित करें : इतिहास अनुभाग को साफ किया


1
मुझे लगता है कि यदि आप इसे नेटवर्किंग स्टैक में निचले स्तर पर हल कर सकते हैं, तो SSRS और SQL नेटिव क्लाइंट को इससे परेशान नहीं होना चाहिए। उदाहरण के लिए यदि आप SSRS सर्वर पर अपने एसक्यूएल सर्वर उदाहरण के लिए एक मार्ग जोड़ सकते हैं तो हमेशा एक विशिष्ट एनआईसी का उपयोग करें जिसे आप इसके साथ दूर कर सकते हैं
टॉम वी - टॉपऑनस्वेर्स.डीक

1
अगर मुझे सही से याद है, SSRS के लिए समर्पित IP केवल एक IIS बाइंडिंग है (रिपोर्ट मूल रूप से एक फैंसी IIS साइट है) और संचार के लिए उपयोग नहीं की जाती है। मेरे पास अपने सिद्धांत का परीक्षण करने का एक तरीका नहीं है, लेकिन मुझे विश्वास नहीं है कि SSRS अपने समर्पित IP पर SQL सर्वर डेटा स्रोतों से संवाद करेगा।
नाथन सी

जवाबों:


6

परिचय

अपने शुरुआती शोध के दौरान मिले विभिन्न दस्तावेज़ों और लिंक और चर्चाओं में दिए गए दस्तावेज़ों के अनुसार, मैं एक ठोस, विश्वसनीय, अनुपालन समाधान के साथ आया हूं।

आरएफसी 3484

द्विआधारी तुलना ने और नीचे किया और लागू किए गए नियम RFC 3484 के अनुसार हैं जो जाहिरा तौर पर IPv4 पतों के लिए भी मान्य हैं।

RFC 3484 भी नियम 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.

मल्टी-विंडोज विंडोज कंप्यूटर पर स्रोत आईपी पता चयन

अब RFC 3484 में सभी नियम IPv4 पतों पर लागू नहीं होते हैं। मल्टी-विंडोज विंडोज कंप्यूटर पर Microsoft ब्लॉग लेख स्रोत आईपी पता चयन बताता है कि कौन से नियम लागू होते हैं।

Windows Vista / Windows Server 2008 व्यवहार के ठीक नीचे एक छोटा सा खंड है जिसमें लिखा है:

XP के समान जब कोई प्रोग्राम एक स्रोत आईपी निर्दिष्ट नहीं करता है, तो स्टैक लक्ष्य आईपी पते को संदर्भित करता है, और फिर पूरे आईपी मार्ग तालिका की जांच करता है ताकि यह सबसे अच्छा नेटवर्क एडाप्टर चुन सके जिस पर पैकेट भेजा जा सके। नेटवर्क एडेप्टर चुने जाने के बाद, स्टैक RFC 3484 में परिभाषित पता चयन प्रक्रिया का उपयोग करता है और आउटबाउंड पैकेट के लिए IP पते के रूप में उस IP पते का उपयोग करता है।

देखने के रूप में मैं SQL / SSRS उदाहरण में केवल एक एनआईसी है पहला भाग मूक है। विंडोज सर्वर हमेशा उपलब्ध एनआईसी को ही चुनेगा।

अब तक Microsoft ब्लॉग के साथ RFC 3484 के संयोजन दोनों IP पतों के स्रोत IP पते के लिए वैध उम्मीदवार हैं। स्पष्टीकरण उत्तर में नीचे दिया गया है।

द केबल गाय

केबल गाई द केबल गाय स्ट्रॉन्ग एंड वेक होस्ट मॉडल्स का एक लेख इस बात पर अधिक जानकारी देता है कि आईपी सिलेक्शन एक स्ट्रॉन्ग होस्ट सेंडिंग एंड रिसीविंग एनवायरनमेंट में और कमजोर होस्ट सेंडिंग एंड रिसीविंग एनवायरनमेंट में कैसे काम करता है। एक अच्छा अतिरिक्त पढ़ा, लेकिन स्रोत आईपी कैसे चुना जाता है, इस पर कोई अधिक प्रकाश नहीं डालता है। यह लेख पहले से ज्ञात आरएफसी 3484 से संबंधित है।

अवर्णनीय समझाते हुए

समाधान की व्याख्या करने के लिए, हमें सबसे पहले आईपी पते को उनके द्विआधारी समकक्षों में बदलना होगा। यह देखकर कि मैंने अपने प्रश्न में गेटवे प्रदान नहीं किए हैं, मैं दो मूल्यों को मानूंगा।

स्रोत आईपी पते और बाइनरी नोटेशन

इसमें शामिल IP पतों के लिए परिवर्तित बाइनरी मानों की एक सूची दी गई है।

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

लक्ष्य आईपी पते और बाइनरी नोटेशन

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

उदाहरण 1: SQL / SSRS इंस्टेंस IP से कम गेटवे IP

इस उदाहरण में मैं यह मानने जा रहा हूं कि गेटवे का आईपी पता SQL सर्वर / SSRS उदाहरण के आईपी पते से कम है, जिसका नाम 168.001.001.002 है।

यदि आप Windows सर्वर और SQL सर्वर / SSRS उदाहरण के बाइनरी पते की तुलना करते हैं, तो आपके पास निम्नलिखित हैं:

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)

परिणाम उदाहरण 1

इस उदाहरण में दोनों आईपी पतों में उच्च क्रम बिट्स (या सबसे लंबे मिलान उपसर्ग) के मिलान की समान मात्रा है। अब तक http.sys प्रक्रिया निवर्तमान संचार के लिए या तो आईपी पते का उपयोग करेगी।

उदाहरण 2: गेटवे IP SQL / SSRS इंस्टेंस IP से अधिक है

इस उदाहरण में मैं यह मानने जा रहा हूं कि गेटवे का आईपी पता SQL सर्वर / SSRS उदाहरण के आईपी पते से अधिक है, अर्थात् 168.001.001.100।

यदि आप Windows सर्वर और SQL सर्वर / SSRS उदाहरण के बाइनरी पते की तुलना करते हैं, तो आपके पास निम्नलिखित हैं:

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)

परिणाम उदाहरण 2

भले ही गेटवे का आईपी पता अब विंडोज सर्वर और एसक्यूएल / एसएसआरएस उदाहरण के आईपी पते से अधिक है, लेकिन उच्च आदेश बिट्स (या सबसे लंबे समय तक मिलान उपसर्ग) के मिलान की मात्रा अभी भी समान है। अब तक http.sys प्रक्रिया निवर्तमान संचार के लिए या तो आईपी पते का उपयोग करेगी।

अब तक के निष्कर्षों का सारांश

अब तक, यह बताना असंभव है कि विंडोज़ सर्वर (.70) पर SQL / SSRS उदाहरण (-71) पर चलने वाले संचार के लिए http.sys प्रक्रिया किस IP पते का उपयोग करेगी।

"जब आपने असंभव को समाप्त कर दिया है, तो जो कुछ भी रहता है, हालांकि अनुचित है, सच्चाई होनी चाहिए" - शर्लक होम्स

ऐसी स्थितियां हैं जहां स्रोत आईपी पता निश्चित रूप से पिन-पॉइंटेड / चयनित / पूर्वनिर्धारित आरएफसी और माइक्रोसॉफ्ट ज्ञान के साथ परिभाषित किया जा सकता है। लेकिन अगर आईपी पते सिर्फ एक-दूसरे के पास और प्रवेश द्वार के पास हैं, तो यह अच्छी तरह से किस्मत से नीचे है। या यह है?

यह देखने के रूप में कि मैं (फ़ायरवॉल) नियम बनाने की स्थिति में हूँ और Microsoft ने एक ...

कार्यान्वयन (कि) के स्रोत पतों के बीच चयन के अन्य साधन हैं। उदाहरण के लिए, यदि कार्यान्वयन किसी तरह से जानता है कि किस स्रोत पते के परिणामस्वरूप "सर्वश्रेष्ठ" संचार प्रदर्शन होगा।

... तो मुझे http.sys प्रक्रिया के आईपी पते को निर्धारित करने के लिए केवल इतना करना है कि वांछित आईपी पते के साथ केवल एक फ़ायरवॉल नियम बनाना है।

क्या होता है

  1. मैं 168.xxx.xxx.71 से 168.xxx.xxx.51: 1433 तक फ़ायरवॉल नियम को परिभाषित करता हूं
  2. SQL / SSRS उदाहरण का http.sys घटक RFC 3484 के साथ अनुपालन करता है और परिभाषित नियमों के अनुसार स्रोत IP का चयन करता है
  3. IP पता 168.xxx.xxx.71 (NIC1 पर) IP पता 168.xxx.xxx.51 पोर्ट 1433 के माध्यम से पहुँचने के लिए स्रोत IP पते के रूप में निर्धारित किया जाता है और इस प्रकार सभी आउटगोइंग पैकेटों को सौंपा जाता है।

लाभ

  1. मैं किसी भी तरह से RFC 3484 के कार्यान्वयन में हस्तक्षेप नहीं कर रहा हूँ
  2. मैं किसी भी तरह से मार्गों या एआरपी कॉन्फ़िगरेशन के साथ नहीं कर रहा हूँ
  3. मैं RFC 3484 और Microsoft के कार्यान्वयन के अनुपालन में हूं
  4. मैं किसी भी रजिस्ट्री सेटिंग्स या सिस्टम कॉन्फ़िगरेशन को हैक नहीं कर रहा हूं
  5. मैं एक छोटी दौड़ कम है

सत्यापन

मेरे पास अभी तक आईपी पते को फ़ायरवॉल नियमों से हटा दिया गया है, लेकिन मुझे विश्वास है कि यह डिज़ाइन / परिभाषित के रूप में काम करेगा। एक सारांश का पालन करेंगे।

इतिहास

संपादित करें 1 प्रारंभिक पोस्ट
संपादित करें 2 उत्तर साफ़ करें , इतिहास अनुभाग जोड़ा गया


1
आपका तर्क उचित लगता है, और आपने स्पष्ट रूप से वर्तमान व्यवहार को निर्धारित करने में काफी प्रयास किया है। हालाँकि, कार्यान्वयन विवरण पर निर्भर रहना खतरनाक है क्योंकि इसकी कोई गारंटी नहीं है कि यह बिना सूचना के नहीं बदलेगा।
जेंस एरिक

क्या हम "डिजाइन द्वारा टूटे" पर पारस्परिक रूप से सहमत हो सकते हैं? मैं सहमत हूं कि मैं RFC 3484 और Microsoft के कार्यान्वयन पर भरोसा कर रहा हूं, लेकिन मेरे पास और क्या विकल्प हैं? क्या मुझे सुरक्षित पक्ष में होने के लिए दोहरे फ़ायरवॉल नियमों के साथ रहना चाहिए?
जॉन उर्फ ​​हॉट

1
हां, दो नियम एकमात्र सुरक्षित विकल्प हैं। मैं पूरी तरह सहमत हूं कि यह सही ढंग से लागू नहीं हुआ है, न ही बहुत अच्छी तरह से।
जेंस एरिक

4

SSRS कई मानक डेटा स्रोतों के साथ-साथ अन्य .NET डेटा स्रोतों का समर्थन करता है:

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

मान लें कि आप डेटा स्रोत के लिए SQL मूल क्लाइंट का उपयोग कर रहे हैं, तो आपके पास स्रोत आईपी पता निर्दिष्ट करने का कोई विकल्प नहीं है:

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

इसलिए यह इस कारण से है कि क्लाइंट नेटवर्क कनेक्शन सेट करते समय बिंद () विधि के दौरान IPADDR_ANY का उपयोग करेगा। यह निर्णय लेने के लिए विंडोज को छोड़ देता है।

Windows 2008 और अप पता चयन अगले होप के साथ मिलान बिट्स की उच्चतम संख्या पर आधारित है जिसका अर्थ है कि उत्तर आपके डिफ़ॉल्ट गेटवे पर निर्भर करता है (या जो कुछ विशिष्ट मार्गों को आपने परिभाषित किया है)।

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

मैंने आपके चित्र में मार्गों या प्रवेशद्वारों का कोई उल्लेख नहीं देखा है, ताकि मुझे जितना मिल सके उतना दूर रहे।

सौभाग्य!


आप या तो 168.xxx.xxx.002 या डिफ़ॉल्ट गेटवे के रूप में 168.xxx.xxx.100 मान सकते हैं। आईपी ​​चयन प्रक्रिया पर इसका कोई प्रभाव नहीं पड़ता है। दोनों IP पते .70 और .71 में एक ही सबसे लंबे मिलान वाले उपसर्ग हैं
जॉन उर्फ ​​हॉट

चूंकि यह अस्पष्ट है, आप या तो Skipassource ( blogs.technet.microsoft.com/rmilne/2012/02/08/… ) का उपयोग कर सकते हैं , हालांकि यह सभी आउटगोइंग ट्रैफ़िक को प्रभावित करेगा। अन्यथा आपको दोनों नियम बनाने होंगे b / c इसमें कोई गारंटी नहीं है; यहां तक ​​कि अगर सिस्टम हमेशा एक ही आईपी को चुनता है, तो भविष्य के अपडेट आपके कॉन्फ़िगरेशन को तोड़ सकते हैं।
जेंस एरिक

मैंने लेख में SKIPASSOURCE पैरामीटर के बारे में पढ़ा और इस निष्कर्ष पर पहुंचा, कि इसे आईपी कार्यान्वयन के भविष्य के संस्करण में हटाया जा सकता है, क्योंकि यह एक हॉटफिक्स के साथ पेश किया गया था।
जॉन उर्फ ​​हॉट

1
मेरे अनुभव (20+ वर्ष) में आमतौर पर हॉटफ़िक्स का उपयोग किया जाता है (1) जल्दी से एक फिक्स प्रदान करें जो पूरी तरह से परीक्षण नहीं किया गया है या (2) एक अस्थायी फिक्स प्रदान करता है जिसके लिए एक स्थायी समाधान विकसित किया जाएगा। किसी भी तरह से मैं उनसे इस क्षमता को हटाने की उम्मीद नहीं करूंगा। हालाँकि, यह आपके शेष b / c के बाकी को नकारात्मक रूप से प्रभावित कर सकता है, आपको अन्य सभी फ़ायरवॉल नियमों को समायोजित करना होगा।
जेन्स एहरिक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.