การจัดการบริการรายงานของ SQL Server (SSRS) IP บนเซิร์ฟเวอร์หลายอินสแตนซ์


9

tl; ดร

ฉันมีอินสแตนซ์ SQL Server (SQLSERVER01-i01) พร้อมที่อยู่ IP เฉพาะและพอร์ต (162.xxx.xxx.51: 1433) บนเซิร์ฟเวอร์ SQL แบบหลายอินสแตนซ์ (อินสแตนซ์ SQL Server แต่ละอินสแตนซ์บนเซิร์ฟเวอร์ Windows มีที่อยู่ IP ของตนเอง ) ซึ่งทำงานบนเซิร์ฟเวอร์ Windows เครื่องเดียว (SQLSERVER01 / 162.xxx.xxx.50)

ฉันยังมีอินสแตนซ์บริการรายงานเฉพาะ (SQLSERVERRS01-i01) พร้อมที่อยู่ IP และพอร์ตของตัวเอง (168.xxx.xxx.71: 1433) ซึ่งทำงานบนเซิร์ฟเวอร์ Windows อื่น (SQLSERVERRS01) ด้วยที่อยู่ IP ของตนเอง (168 .xxx.xxx.70)

ทุ่มเทเซิร์ฟเวอร์บริการรายงานมีแอพลิเคชันAPPL1ซึ่งสามารถเข้าถึงได้ผ่านทางหรือผ่านทาง http://SQLSERVERRS01-i01:80/Reports_APPL1http://SQLSERVERRS01:80/Reports_APPL1

SSRS จะรับคำขอทั้งสองเนื่องจากการ*:80กำหนดค่าในการกำหนดค่าบริการรายงานสำหรับส่วนหัวของโฮสต์

เรามีไฟร์วอลล์หลายตัวระหว่างช่วง IP แต่ละช่วงซึ่งหมายความว่าเราต้องใช้กฎเฉพาะสำหรับการเชื่อมต่อ IP-to-IP หรือ IPrange-to-IP แต่ละตัว อย่างไรก็ตามเมื่อเซิร์ฟเวอร์สองเครื่องมีส่วนเกี่ยวข้องความปลอดภัยจะกำหนดว่าต้องเป็นกฎ IP-to-IP ในไฟร์วอลล์เสมอ

คำถาม

(ขึ้นอยู่กับภาพหน้าจอลงไปอีก)

เมื่อเซิร์ฟเวอร์ Reporting Services เชื่อมต่อกับอินสแตนซ์ SQL Server (บน 162.xxx.xxx.51) เพื่อดึงข้อมูลมันจะสร้างการเชื่อมต่อกับที่อยู่ IP พื้นฐานของเซิร์ฟเวอร์ Windows (168.xxx.xxx.70 / ที่ต้องการ) เสมอ ) SSRS นั้นกำลังทำงานอยู่หรือบางครั้งจะใช้ที่อยู่ IP ของอินสแตนซ์ของบริการรายงานของ SQL Server (168.xxx.xxx.71)

สิ่งนี้เกี่ยวข้องกับการกำหนดค่ากฎไฟร์วอลล์โดยใช้วิธี IP-to-IP ฉันจะต้องสมัครกฎที่กำหนดการเชื่อมต่อ 168.xxx.xxx.71 ถึง 162.xxx.xxx.51 ผ่านพอร์ต 1433 หรือ 168.xxx.xxx.70 ถึง 162.xxx.xxx.51 ผ่านทาง พอร์ต 1433

ปัจจุบันฉันจะสมัครกฎไฟร์วอลล์ทั้งสอง

คำถามโบนัส

ฉันสามารถกำหนดค่าเซิร์ฟเวอร์ Reporting Services เพื่อสื่อสารกับที่อยู่ IP เฉพาะได้หรือไม่ ในกรณีนี้มีที่อยู่ 168.xxx.xxx.71

คำตอบฉันไม่ได้มองหา

ฉันไม่ได้ขอคำแนะนำเกี่ยวกับวิธีปรับแต่งการกำหนดค่าไฟร์วอลล์ให้เหมาะสมหรือวิธีการนำแนวคิดการแบ่งเขตสำหรับเครือข่ายของเราไปใช้ (มันอยู่ในขั้นตอนการส่งแล้ว) นอกจากนี้ฉันไม่สนใจข้อเสนอแนะที่มี SQL Server และ SSRS บนเซิร์ฟเวอร์เดียวกันจะแก้ไขปัญหาของฉัน ฉันรู้ว่าและยินดีที่จะทำ แต่สำหรับซอฟต์แวร์บุคคลที่สามที่จำเป็นในการทำงานร่วมกับส่วนประกอบ SSRS

มันได้ผล

การกำหนดค่าฉันใช้งานได้หากฉันใช้กฎไฟร์วอลล์ทั้งสองระหว่างอินสแตนซ์ SSRS และ SQL Server

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

ฉันต้องการลดกฎไฟร์วอลล์หนึ่งกฎอย่างปลอดภัยและตรวจสอบให้แน่ใจว่าทุกสิ่งยังคงทำงานได้ (ดูภาพหน้าจอเพิ่มเติมลงไป)
แก้ไข:บทความที่ฉันอ่านมาแล้วจะแนะนำว่าฉันต้องการเพียงกฎข้อที่สอง แต่ไม่มีการรับประกันใด ๆ

บทความที่ฉันได้ปรึกษาไปแล้ว

  1. ข้อควรพิจารณาด้านความปลอดภัยสำหรับ
    บทความฐานการติดตั้งเซิร์ฟเวอร์ SQL

  2. กำหนดค่าไฟร์วอลล์ Windows เพื่ออนุญาตให้เข้าถึงเซิร์ฟเวอร์ SQL
    บทความนี้ชี้ไปที่บทความอื่น ๆ ทั้งหมดที่เกี่ยวข้องกับการกำหนดค่าไฟร์วอลล์สำหรับ SQL Server

  3. กำหนดค่าไฟร์วอลล์ Windows สำหรับการเข้าถึงโปรแกรมฐานข้อมูล
    ไม่มีคำที่อยู่ IP ที่ใช้

  4. กำหนดค่าไฟร์วอลล์สำหรับการเข้าถึงเซิร์ฟเวอร์รายงาน
    บทความนี้ค่อนข้างน่าสนใจตามที่ระบุไว้:

    ถ้าคุณกำลังเข้าถึงฐานข้อมูลเชิงสัมพันธ์ของ SQL Server บนคอมพิวเตอร์ภายนอกหรือถ้าฐานข้อมูลเซิร์ฟเวอร์รายงานอยู่ในอินสแตนซ์ของ SQL Server ภายนอกคุณต้องเปิดพอร์ต 1433 และ 1434 บนคอมพิวเตอร์ภายนอก

    ... แต่ยังไม่ใช่คำที่เกี่ยวกับการกำหนดค่า / การตั้งค่า / ค่าเริ่มต้นของ IP

  5. การเลือกที่อยู่ IP ต้นทางในคอมพิวเตอร์ Windows แบบหลาย Homed

  6. ฟังก์ชันการทำงานสำหรับการเลือกที่อยู่ IP ต้นทางใน Windows Server 2008 และใน Windows Vista นั้นแตกต่างจากฟังก์ชันการทำงานที่สอดคล้องกันใน Windows รุ่นก่อนหน้า

บทความที่ 5 และ 6 ได้รับการมอบให้โดยJames (dba.se) ขณะนี้พวกเขาดูเหมือนจะเป็นคำตอบที่เหมาะสมที่สุด อย่างไรก็ตามฉันสงสัยว่าบทความหนึ่งกล่าวถึงการใช้ NIC หลายตัวในขณะที่ฉันมี NIC เพียงหนึ่งเดียวที่มี IP หลาย ๆ ตัวที่ได้รับมอบหมาย ทอม (dba.se) ก็บิ่นด้วยคำแนะนำและความคิดเห็นทั่วไป

ทำไมที่นี่และไม่อยู่ใน dba.stackexchange.com

ในตอนแรกฉันลังเลที่จะโพสต์คำถามนี้ใน serverfault.com เนื่องจากลักษณะซับซ้อนของคำถาม คำถามนี้มีแนวโน้มที่จะเป็น SQL Server ที่เฉพาะเจาะจง แต่ยังรวมถึง Windows Server ที่เฉพาะเจาะจง ในที่สุดฉันตัดสินใจที่จะโพสต์ที่นี่เพราะฉันคิดว่ามันเป็น Windows Server IP จัดการสิ่งต่าง ๆ (สำหรับการสูญเสียคำที่ดีกว่า)

หากผู้ดำเนินรายการคิดว่าฉันจะได้รับการตอบสนองที่ดีขึ้นใน dba.stackexchange.com โปรดย้ายคำถามไปที่นั่น

คำอธิบายแบบยาว

ในสภาพแวดล้อมของเราเรามีเซิร์ฟเวอร์ Windows ที่โฮสต์อินสแตนซ์ SQL Server หลายรายการและการตั้งค่า IP หลายรายการ เราเพิ่มการกำหนดค่าไฟร์วอลล์ที่ซับซ้อนเซิร์ฟเวอร์ SQL Server Reporting Services (SSRS) เฉพาะและมาพร้อมกับสภาพแวดล้อมที่มีลักษณะเช่นนี้:

ภาพรวมสภาพแวดล้อม

โดยทั่วไปเราสามารถมี Windows Server หนึ่งเซิร์ฟเวอร์ที่ทำงานได้ถึง 15 (สิบห้า) อินสแตนซ์ของ SQL Server บนที่อยู่ IP แต่ละรายการ เช่นเดียวกับอินสแตนซ์บริการรายงานเฉพาะ

กฎไฟร์วอลล์

ช่วง IP ที่แตกต่างกันยังไม่ได้กำหนดค่าเป็นโซนซึ่งหมายความว่าเราต้องกำหนดค่ากฎไฟร์วอลล์แต่ละข้อแยกกันเป็นกฎ IP-to-IP หรือ IPrange-to-IP เมื่อเซิร์ฟเวอร์สองเครื่องมีส่วนเกี่ยวข้องความปลอดภัยจะบอกว่าต้องเป็นกฎ IP-to-IP เสมอ แต่ละอินสแตนซ์ของ SQL Server จะมีชุดกฎของตัวเองสำหรับไฟร์วอลล์ที่เกี่ยวข้องกับการสื่อสารไม่ว่าจะเป็นการเชื่อมโยงระหว่างเซิร์ฟเวอร์กับเซิร์ฟเวอร์หรือไคลเอนต์ต่อเซิร์ฟเวอร์ การสมัครกฎไฟร์วอลล์ในปัจจุบันมีระยะเวลารอสี่ถึงหกสัปดาห์ การลดปริมาณของกฎไฟร์วอลล์จะช่วยลดความกดดันในทีมรักษาความปลอดภัยเครือข่าย

การกำหนดค่า IP อินสแตนซ์ของเซิร์ฟเวอร์ SQL

การกำหนดค่าอินสแตนซ์ SQL Server เพื่อรับเฉพาะบน IP เฉพาะและพอร์ตจะดำเนินการโดยการแก้ไขการตั้งค่าบางอย่างในยูทิลิตี้ตัวจัดการการกำหนดค่าเซิร์ฟเวอร์ SQL ขั้นตอนแรกคือการเริ่มต้นตัวจัดการการกำหนดค่าเซิร์ฟเวอร์ SQLและในส่วนด้านซ้ายให้เลือกการกำหนดค่าเครือข่ายเซิร์ฟเวอร์ SQL | โปรโตคอลสำหรับ InstanceName ในบานหน้าต่างด้านซ้ายคลิกซ้ายที่ชื่อโปรโตคอล TCP / IPและเปิดใช้งานโปรโตคอล จากนั้นคลิกซ้ายโปรโตคอลอีกครั้งและนำมาขึ้นอสังหาริมทรัพย์สำหรับ TCP / IPหน้าต่าง

จากนั้นตรวจสอบให้แน่ใจว่ามีการตั้งค่าต่อไปนี้ในการลงทะเบียนโพรโทคอล :

Enabled           : Yes
Listen All        : No

ในการลงทะเบียนที่อยู่ IPตรวจสอบการตั้งค่าต่อไปนี้สำหรับที่อยู่ IP ที่เป็นปัญหา (เช่นสำหรับเซิร์ฟเวอร์ Reporting Services ในตัวอย่างนี้จะเป็น 168.xxx.xxx.71)

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

หมายเหตุ:สิ่งสำคัญคือการตั้งค่าสำหรับ TCP Dynamic Ports ว่างเปล่าไม่ใช่แค่ 0 (ศูนย์)

ตอนนี้คุณมีอินสแตนซ์ของ SQL Server ที่จะรับเฉพาะการเชื่อมต่อฐานข้อมูลบน 168.xxx.xxx.71 โดยใช้พอร์ต 1433

สรุปอินสแตนซ์ของเซิร์ฟเวอร์ SQL

บริการ SQL Server Browser ไม่ทำงานและแต่ละ SQL Server แต่ละอินสแตนซ์ถูกกำหนดค่าให้ใช้เฉพาะที่อยู่ IP ของตนเองบนพอร์ต 1433 รับอินสแตนซ์ของ SQL Server ชื่อ GENERAL เซิร์ฟเวอร์ Windows ที่มีชื่อโฮสต์ 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 Server จะไม่รับการร้องขอสำหรับ 162.xxx.xxx.50: 1433 เนื่องจากไม่มีการกำหนดค่าอินสแตนซ์ของ SQL Server ให้รับฟังที่อยู่ IP นี้ในยูทิลิตี้ตัวจัดการการกำหนดค่าเซิร์ฟเวอร์ SQL SQL Server จะรับการร้องขอสำหรับ SQLSERVER01-i01 (บนพอร์ต 1433) หรือ 162.xxx.xxx.51,1433 เท่านั้น

สรุปอินสแตนซ์ของบริการรายงานของ SQL Server

บริการเบราว์เซอร์เซิร์ฟเวอร์ SQL ไม่ทำงานและแต่ละอินสแตนซ์ของบริการรายงานเซิร์ฟเวอร์ SQL แต่ละรายการถูกกำหนดค่าให้ใช้เฉพาะที่อยู่ IP ของตนเองบนพอร์ต 1433 เนื่องจากอินสแตนซ์ของบริการรายงานเซิร์ฟเวอร์ SQL ที่เรียกว่า GENERAL เซิร์ฟเวอร์ Windows ที่มีชื่อโฮสต์ SQLSERVERRS01 บน 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 Server จะไม่รับการร้องขอสำหรับ 168.xxx.xxx.70: 1433 เนื่องจากไม่มีการกำหนดค่าอินสแตนซ์ของ SQL Server ให้รับฟังที่อยู่ IP นี้ในยูทิลิตี้ตัวจัดการการกำหนดค่าเซิร์ฟเวอร์ SQL SQL Server จะรับการร้องขอสำหรับ SQLSERVER01-i01 (บนพอร์ต 1433) หรือ 162.xxx.xxx.71,1433 เท่านั้น

SSRS จะรับคำขอสำหรับ http: // sqlserverrs01-i01 / Reports_APPL1หรือhttp: // sqlserverrs01 / Reports_APPL1เนื่องจากการ *: 80 กำหนดค่าในการกำหนดค่าบริการรายงานสำหรับส่วนหัวของโฮสต์

ฉันหวังว่าฉันได้ให้ข้อมูลที่เพียงพอสำหรับทุกคนที่เต็มใจใช้เวลาในการเขียนคำตอบและฉันหวังว่าจะได้รายละเอียดทางเทคนิคและลิงก์ของคุณ

เขียนด้วยStackEditและปรับเปลี่ยนในภายหลังด้วยตนเองเพื่อให้เข้ากันได้กับ stackexchange

ประวัติศาสตร์

แก้ไข 1 : รีลีสเริ่มต้น
แก้ไข 2 : ฟอร์แมตใหม่เพื่อให้อ่านง่าย ย้ายคำอธิบาย SF / DB ลงแล้ว เพิ่มชื่อโฮสต์สำหรับ Windows Server
แก้ไข 3 : แก้ไขที่อยู่ IP ผิดในรายการกฎของไฟร์วอลล์
แก้ไข 4 : เปลี่ยนคำว่าโฮสติ้งเป็นเรียกใช้ (เป็นสภาพแวดล้อมที่ไม่ใช่แบบเสมือนจริง) ในบางสถานที่ เพิ่มที่อยู่ IP ในประโยคเดียว
แก้ไข 5 : เพิ่มรายการบทความที่ฉันปรึกษาและสนับสนุนแล้วอ้างอิง
6 แก้ไข : ล้างข้อมูลในส่วนประวัติ


1
ฉันคิดว่าถ้าคุณสามารถแก้ปัญหาได้ในระดับที่ต่ำกว่าในเครือข่ายสแต็ค SSRS และ SQL Native ไคลเอ็นต์ไม่ควรต้องใส่ใจ ตัวอย่างเช่นหากคุณสามารถเพิ่มเส้นทางไปยังอินสแตนซ์ SQL Server ของคุณบนเซิร์ฟเวอร์ SSRS เพื่อใช้ NIC เฉพาะที่คุณสามารถทำได้
Tom V - ลอง topanswers.xyz

1
หากฉันจำได้อย่างถูกต้อง IP เฉพาะสำหรับ SSRS นั้นเป็นเพียงการเชื่อมโยงกับ IIS (โดยทั่วไปแล้วรายงานจะเป็นไซต์ IIS แฟนซี) และไม่ได้ใช้สำหรับการสื่อสาร ฉันไม่มีวิธีทดสอบทฤษฎีของฉัน แต่ฉันไม่เชื่อว่า SSRS จะสื่อสารกับแหล่งข้อมูล SQL Server ผ่าน IP เฉพาะของตน
นาธาน C

คำตอบ:


6

บทนำ

จากเอกสารต่าง ๆ ที่ฉันพบระหว่างการวิจัยครั้งแรกของฉันและเอกสารที่ให้ไว้ในลิงก์และการอภิปรายฉันได้พบกับโซลูชันที่มั่นคงเชื่อถือได้และสอดคล้อง

RFC 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.

การเลือกที่อยู่ IP ต้นทางในคอมพิวเตอร์ Windows แบบหลาย Homed

ตอนนี้ไม่ใช่กฎทั้งหมดใน RFC 3484 ที่ใช้กับที่อยู่ IPv4 บทความในบล็อก Microsoft ของ Microsoft การเลือกที่อยู่ IP ของแหล่งข้อมูลบนคอมพิวเตอร์ที่ใช้ Windows หลายบ้านอธิบายถึงกฎที่ใช้

มีส่วนเล็ก ๆ ด้านล่างWindows Vista / Windows Server 2008 Behaviorที่อ่าน:

คล้ายกับ XP เมื่อหากโปรแกรมไม่ระบุ IP ต้นทางสแต็กจะอ้างอิงที่อยู่ IP เป้าหมายจากนั้นตรวจสอบตารางเส้นทาง IP ทั้งหมดเพื่อให้สามารถเลือกอะแดปเตอร์เครือข่ายที่ดีที่สุดที่จะส่งแพ็คเก็ต หลังจากเลือกอะแดปเตอร์เครือข่ายแล้วสแต็กจะใช้กระบวนการเลือกที่อยู่ที่กำหนดไว้ใน RFC 3484 และใช้ที่อยู่ IP นั้นเป็นที่อยู่ IP ต้นทางสำหรับแพ็กเก็ตขาออก

เห็นเป็นฉันมีเพียงหนึ่ง NIC ในอินสแตนซ์ SQL / SSRS ส่วนแรกคือ moot Windows Server จะเลือกเฉพาะ NIC ที่มีอยู่เสมอ

จนถึงขณะนี้การรวม RFC 3484 กับผลลัพธ์บล็อก Microsoft ในที่อยู่ IP ทั้งสองนั้นเป็นตัวเลือกที่ถูกต้องสำหรับที่อยู่ IP ต้นทาง คำอธิบายดังต่อไปนี้ลงในคำตอบ

The Cable Guy

บทความจากเคเบิ้ลกายสายรัดแข็งและจุดอ่อนรุ่นโฮสต์จะเข้าสู่รายละเอียดเพิ่มเติมเกี่ยวกับวิธีการเลือก IP ทำงานในโฮสต์ที่แข็งแกร่งการส่งและรับสภาพแวดล้อมและในโฮสต์อ่อนแอส่งและรับสภาพแวดล้อม การอ่านเพิ่มเติมที่ดี แต่ไม่ให้ความกระจ่างเกี่ยวกับวิธีเลือก IP ต้นทาง บทความนี้เกี่ยวข้องกับ RFC 3484 ที่รู้จักกันดีอยู่แล้ว

อธิบายสิ่งที่อธิบายไม่ได้

เพื่ออธิบายวิธีการแก้ปัญหาอันดับแรกเราต้องแปลงที่อยู่ IP ที่เป็นปัญหาให้เทียบเท่าไบนารีของพวกเขา เห็นว่าฉันไม่ได้ให้เกตเวย์ในคำถามของฉันฉันจะถือว่าสองค่า

ที่อยู่ IP ต้นทางและสัญลักษณ์ไบนารี

นี่คือรายการของค่าไบนารีที่แปลงแล้วสำหรับที่อยู่ 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

ที่อยู่ IP เป้าหมายและสัญลักษณ์ไบนารี

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

ตัวอย่างที่ 1: เกตเวย์ IP ต่ำกว่า IP ของอินสแตนซ์ของ SQL / SSRS

ในตัวอย่างนี้ฉันจะสมมติว่าที่อยู่ IP ของเกตเวย์ต่ำกว่าที่อยู่ IP ของอินสแตนซ์ของ SQL Server / SSRS นั่นคือ 168.001.001.002

หากคุณเปรียบเทียบทั้งสองที่อยู่ไบนารีของอินสแตนซ์ของ Windows Server และ SQL Server / 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

ในตัวอย่างนี้ที่อยู่ IP ทั้งสองมีจำนวนบิตการจับคู่ลำดับสูงเท่ากัน (หรือส่วนนำหน้าการจับคู่ที่ยาวที่สุด) จนถึงตอนนี้กระบวนการ http.sys จะใช้หนึ่งในที่อยู่ IP สำหรับการสื่อสารขาออก

ตัวอย่างที่ 2: เกตเวย์ IP สูงกว่า SQL / SSRS อินสแตนซ์ IP

ในตัวอย่างนี้ฉันจะสมมติว่าที่อยู่ IP ของเกตเวย์สูงกว่าที่อยู่ IP ของอินสแตนซ์ของ SQL Server / SSRS นั่นคือ 168.001.001.100

หากคุณเปรียบเทียบทั้งสองที่อยู่ไบนารีของอินสแตนซ์ของ Windows Server และ SQL Server / 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

แม้ว่าที่อยู่ IP ของเกตเวย์จะสูงกว่าที่อยู่ IP ของเซิร์ฟเวอร์ Windows และอินสแตนซ์ของ SQL / SSRS จำนวนบิตการจับคู่บิตคำสั่งสูง (หรือคำนำหน้าการจับคู่ที่ยาวที่สุด) ยังคงเหมือนเดิม จนถึงตอนนี้กระบวนการ http.sys จะใช้หนึ่งในที่อยู่ IP สำหรับการสื่อสารขาออก

สรุปผลการวิจัยจนถึง

จนถึงขณะนี้ยังไม่สามารถบอกได้ว่าที่อยู่ IP ใดที่กระบวนการ http.sys จะใช้สำหรับการสื่อสารขาออกที่ทำงานบนอินสแตนซ์ SQL / SSRS (.71) บนเซิร์ฟเวอร์ windows (.70)

"เมื่อคุณกำจัดสิ่งที่เป็นไปไม่ได้สิ่งที่เหลืออยู่ไม่น่าเป็นไปได้จะต้องเป็นความจริง" - Sherlock Holmes

มีสถานการณ์ที่ที่อยู่ IP ของแหล่งที่มาสามารถพินชี้ / เลือก / กำหนดอย่างแน่นอนด้วยความรู้ RFC และ Microsoft ดังกล่าว แต่ถ้าที่อยู่ IP ใกล้กันเกินไปและใกล้กับเกตเวย์ก็เป็นเรื่องโชคดี หรือมันคืออะไร?

เห็นฉันอยู่ในตำแหน่งของการสร้างกฎ (ไฟร์วอลล์) และ Microsoft มี ...

การนำไปใช้ (นั้น) มีวิธีการอื่นในการเลือกระหว่างที่อยู่ต้นทาง ตัวอย่างเช่นหากการดำเนินการอย่างใดรู้ว่าแหล่งที่อยู่ใดจะส่งผลให้ประสิทธิภาพการสื่อสาร "ดีที่สุด"

... จากนั้นทั้งหมดที่ฉันต้องทำเพื่อกำหนดที่อยู่ IP ของกระบวนการ http.sysคือการสร้างกฎไฟร์วอลล์เพียงอันเดียวที่มีที่อยู่ IP ที่ต้องการ

เกิดอะไรขึ้น

  1. ฉันกำหนดกฎไฟร์วอลล์จาก 168.xxx.xxx.71 ถึง 168.xxx.xxx.51: 1433
  2. องค์ประกอบ http.sys ของอินสแตนซ์ SQL / SSRS เป็นไปตาม RFC 3484 และเลือก IP ต้นทางตามกฎที่กำหนดไว้
  3. ที่อยู่ IP 168.xxx.xxx.71 (บน NIC1) ถูกกำหนดเป็นที่อยู่ IP ต้นทางเพื่อเข้าถึงที่อยู่ IP 168.xxx.xxx.51 ผ่านพอร์ต 1433 และได้รับการกำหนดให้กับแพ็กเก็ตขาออกทั้งหมด

ประโยชน์ที่ได้รับ

  1. ฉันไม่รบกวนการใช้งาน RFC 3484
  2. ฉันไม่สามารถเล่นกับเส้นทางหรือการกำหนดค่า ARP ได้
  3. ฉันเป็นไปตาม RFC 3484 และการใช้งานของ Microsoft
  4. ฉันไม่แฮ็คการตั้งค่ารีจิสทรีหรือการกำหนดค่าระบบ
  5. ฉันมีกฎข้อหนึ่งข้อต่อหนึ่งข้อ

การตรวจสอบ

ฉันยังไม่ได้ลบที่อยู่ IP ออกจากกฎไฟร์วอลล์ แต่ฉันมั่นใจว่ามันจะทำงานได้ตามที่ออกแบบ / กำหนดไว้ สรุปจะตามมา

ประวัติศาสตร์

แก้ไข 1โพสต์ครั้งแรก
แก้ไข 2ล้างคำตอบส่วนเพิ่มประวัติ


1
ตรรกะของคุณดูสมเหตุสมผลและคุณใช้ความพยายามอย่างมากในการกำหนดพฤติกรรมปัจจุบัน อย่างไรก็ตามการใช้รายละเอียดการดำเนินการนั้นเป็นสิ่งที่อันตรายเนื่องจากไม่มีการรับประกันว่าจะไม่มีการเปลี่ยนแปลงโดยไม่ต้องแจ้งให้ทราบล่วงหน้า
Jens Ehrich

เราสามารถตกลงร่วมกันเกี่ยวกับ "การออกแบบโดยหัก" ได้ไหม ฉันยอมรับว่าฉันใช้ RFC 3484 และการใช้งานของ Microsoft แต่มีตัวเลือกอื่น ๆ อีกบ้าง ฉันควรติดตั้งกฎคู่ของไฟร์วอลล์เพื่อให้ปลอดภัยหรือไม่?
John aka hot2use

1
ใช่กฎสองข้อเป็นตัวเลือกที่ปลอดภัยเท่านั้น ฉันยอมรับอย่างเต็มที่ว่ามันไม่ได้ใช้งานอย่างถูกต้องหรือดี
Jens Ehrich

4

SSRS รองรับแหล่งข้อมูลมาตรฐานหลายแหล่งรวมถึงแหล่งข้อมูล. NET อื่น ๆ :

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

สมมติว่าคุณกำลังใช้ไคลเอ็นต์เนทีฟ SQL สำหรับแหล่งข้อมูลคุณไม่มีตัวเลือกในการระบุที่อยู่ IP ต้นทาง:

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

ดังนั้นจึงเป็นเหตุผลที่ลูกค้าจะใช้ IPADDR_ANY ระหว่างวิธีการผูก () เมื่อตั้งค่าการเชื่อมต่อเครือข่าย สิ่งนี้จะทำให้ Windows ตัดสินใจได้

Windows 2008 และการเลือกที่อยู่ขึ้นอยู่กับจำนวนบิตการจับคู่สูงสุดกับ hop ถัดไปซึ่งหมายความว่าคำตอบนั้นขึ้นอยู่กับเกตเวย์เริ่มต้นของคุณ (หรือเส้นทางใด ๆ ที่คุณกำหนดไว้)

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 ทั้งที่อยู่ IP .70 และ. 71 มีคำนำหน้าการจับคู่ที่ยาวที่สุดเท่ากัน
John aka hot2use

เนื่องจากเป็นสิ่งที่คลุมเครือคุณสามารถใช้ skipassource ( blogs.technet.microsoft.com/rmilne/2012/02/08/… ) อย่างไรก็ตามสิ่งนี้อาจส่งผลต่อการรับส่งข้อมูลขาออกทั้งหมด มิฉะนั้นคุณจะต้องสร้างกฎทั้งสอง b / c ไม่มีการรับประกันเลย แม้ว่าระบบจะเลือก IP เดียวกันเสมอการอัปเดตในอนาคตอาจทำให้การกำหนดค่าของคุณเสียหาย
Jens Ehrich

ฉันอ่านเกี่ยวกับพารามิเตอร์ SKIPASSOURCE ในบทความและมาถึงข้อสรุปว่าอาจถูกลบในการใช้งาน IP เวอร์ชันในอนาคตเนื่องจากมีการนำมาใช้กับโปรแกรมแก้ไขด่วน
John aka hot2use

1
จากประสบการณ์ของฉัน (20 ปีขึ้นไป) มักจะใช้โปรแกรมแก้ไขด่วนเพื่อ (1) ระบุการแก้ไขที่ยังไม่ผ่านการทดสอบอย่างสมบูรณ์หรือ (2) ให้การแก้ไขชั่วคราวซึ่งจะพัฒนาโซลูชันถาวร ไม่ว่าฉันจะคาดหวังให้พวกเขาลบความสามารถนี้ อย่างไรก็ตามอาจส่งผลเสียต่อส่วนที่เหลือของการกำหนดค่า b / c ที่คุณจะต้องปรับกฎไฟร์วอลล์อื่น ๆ ทั้งหมด
Jens Ehrich
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.