Xử lý IP Dịch vụ báo cáo máy chủ SQL (SSRS) trên máy chủ đa trường


9

Tl; Tiến sĩ

Tôi có một phiên bản SQL Server (SQLSERVER01-i01) với một địa chỉ IP và cổng chuyên dụng (162.xxx.xxx.51: 1433) trên SQL Server đa phiên bản (mỗi phiên bản SQL Server trên Windows Server có địa chỉ IP riêng ) tất cả đang chạy trên một máy chủ Windows (SQLSERVER01 / 162.xxx.xxx.50).

Tôi cũng có một phiên bản Dịch vụ báo cáo chuyên dụng (SQLSERVERRS01-i01) với địa chỉ IP và cổng riêng (168.xxx.xxx.71: 1433), đang chạy trên một máy chủ Windows khác (SQLSERVERRS01) với địa chỉ IP riêng (168 .xxx.xxx, 70).

Máy chủ Dịch vụ báo cáo chuyên dụng có một ứng dụng APPL1có thể truy cập thông qua http://SQLSERVERRS01-i01:80/Reports_APPL1hoặc thông qua http://SQLSERVERRS01:80/Reports_APPL1.

SSRS sẽ nhận cả hai yêu cầu do *:80cấu hình trong Cấu hình dịch vụ báo cáo cho các tiêu đề máy chủ.

Chúng tôi có nhiều tường lửa giữa mỗi dải IP, điều đó có nghĩa là chúng tôi phải áp dụng một quy tắc cụ thể cho từng kết nối IP-to-IP hoặc IPrange-to-IP. Tuy nhiên, khi có hai máy chủ tham gia, thì bảo mật ra lệnh rằng nó luôn phải là quy tắc IP-to-IP trong tường lửa.

Câu hỏi

(dựa trên ảnh chụp màn hình xuống hơn nữa)

Khi máy chủ Dịch vụ báo cáo kết nối với phiên bản SQL Server (trên 162.xxx.xxx.51) để truy xuất dữ liệu, nó sẽ luôn tạo kết nối với địa chỉ IP cơ bản của máy chủ Windows (168.xxx.xxx, 70 / ưa thích ) SSRS đang chạy hoặc đôi khi (đôi khi) sẽ sử dụng địa chỉ IP của phiên bản Dịch vụ báo cáo máy chủ SQL (168.xxx.xxx.71)?

Điều này có liên quan đến cấu hình của quy tắc tường lửa bằng cách sử dụng phương pháp IP-to-IP. Tôi sẽ phải áp dụng quy tắc xác định kết nối 168.xxx.xxx.71 đến 162.xxx.xxx.51 qua cổng 1433 hoặc kết nối 168.xxx.xxx70 đến 162.xxx.xxx.51 qua cổng 1433.

Hiện tại tôi sẽ áp dụng cho cả hai quy tắc tường lửa.

Câu hỏi thưởng

Tôi có thể định cấu hình máy chủ Dịch vụ báo cáo để liên lạc với một địa chỉ IP chuyên dụng không? Trong trường hợp này với địa chỉ 168.xxx.xxx.71.

Câu trả lời tôi không tìm kiếm

Tôi không tìm kiếm lời khuyên về cách tối ưu hóa cấu hình tường lửa hoặc cách triển khai khái niệm phân vùng cho các mạng của chúng tôi. (Nó đã có trong đường ống). Ngoài ra, tôi không quan tâm đến phản hồi cho thấy rằng có SQL Server và SSRS trên cùng một máy chủ sẽ giải quyết các vấn đề của tôi. Tôi biết điều đó và sẵn sàng làm điều đó nhưng đối với phần mềm của bên thứ ba bắt buộc phải chạy cùng với các thành phần SSRS.

Nó hoạt động

Cấu hình tôi có hoạt động nếu tôi áp dụng cả hai quy tắc tường lửa giữa phiên bản SSRS và SQL Server.

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

Tôi muốn giảm một cách an toàn theo một quy tắc tường lửa và đảm bảo rằng mọi thứ sẽ vẫn hoạt động. (Xem ảnh chụp màn hình tiếp theo xuống)
Chỉnh sửa: Các bài viết tôi đã đọc cho đến nay cho thấy tôi chỉ cần quy tắc thứ hai, nhưng không có gì đảm bảo.

Bài viết tôi đã tham khảo ý kiến

  1. Cân nhắc bảo mật cho
    bài viết Cơ sở cài đặt máy chủ SQL .

  2. Định cấu hình Tường lửa Windows để Cho phép Truy cập Máy chủ SQL
    Bài viết này chỉ đến tất cả các bài viết khác liên quan đến cấu hình tường lửa cho SQL Server.

  3. Cấu hình tường lửa Windows để truy cập công cụ cơ sở dữ liệu
    Không sử dụng từ địa chỉ IP nào.

  4. Cấu hình tường lửa để truy cập máy chủ báo cáo
    Bài viết này khá thú vị như đã lưu ý:

    Nếu bạn đang truy cập cơ sở dữ liệu quan hệ SQL Server trên các máy tính bên ngoài hoặc nếu cơ sở dữ liệu máy chủ báo cáo nằm trên phiên bản SQL Server bên ngoài, bạn phải mở cổng 1433 và 1434 trên máy tính bên ngoài.

    ... nhưng vẫn không nói gì về cấu hình / cài đặt / mặc định IP.

  5. Lựa chọn địa chỉ IP nguồn trên máy tính Windows nhiều Homed

  6. Chức năng lựa chọn địa chỉ IP nguồn trong Windows Server 2008 và Windows Vista khác với chức năng tương ứng trong các phiên bản trước của Windows

Điều 5 & 6 được James (dba.se) cung cấp cho tôi . Họ hiện có vẻ là câu trả lời thích hợp nhất. Tuy nhiên tôi hơi nghi ngờ rằng một bài viết đề cập đến việc sử dụng nhiều NIC trong khi tôi chỉ có một NIC với nhiều IP được gán cho nó. Tom (dba.se) cũng đã sứt mẻ với lời khuyên và nhận xét chung.

Tại sao ở đây và không có trong dba.stackexchange.com

Lúc đầu tôi đã miễn cưỡng đăng câu hỏi này lên serverfault.com vì tính chất phức tạp của câu hỏi. Câu hỏi có cả hai xu hướng là cụ thể của SQL Server, nhưng cũng là dành riêng cho Windows Server. Cuối cùng, tôi quyết định đăng nó ở đây, vì tôi nghĩ rằng đó là một Windows Server IP xử lý (vì mất từ ​​tốt hơn).

Nếu người điều hành nghĩ rằng tôi sẽ nhận được phản hồi tốt hơn trong dba.stackexchange.com thì vui lòng chuyển câu hỏi sang đó.

Giải thích dài

Trong môi trường của chúng tôi, chúng tôi có máy chủ Windows lưu trữ nhiều phiên bản SQL Server và nhiều cài đặt IP. Chúng tôi thêm các cấu hình tường lửa phức tạp, các máy chủ Dịch vụ báo cáo SQL Server (SSRS) chuyên dụng và đưa ra một môi trường trông giống như thế này:

Tổng quan về môi trường

Về cơ bản, chúng ta có thể có một Máy chủ Windows chạy tối đa 15 (mười lăm) phiên bản SQL Server trên các địa chỉ IP riêng lẻ. Điều này cũng hợp lệ đối với trường hợp Dịch vụ báo cáo chuyên dụng.

Quy tắc tường lửa

Các phạm vi IP khác nhau hiện không được định cấu hình là các vùng, điều đó có nghĩa là chúng ta phải định cấu hình độc lập từng quy tắc tường lửa dưới dạng quy tắc IP-to-IP hoặc IPrange-to-IP. Khi có hai máy chủ tham gia, thì bảo mật sẽ ra lệnh rằng nó luôn phải là quy tắc IP-to-IP. Mỗi phiên bản SQL Server sẽ có một bộ quy tắc riêng cho các tường lửa liên quan đến truyền thông, đây có thể là liên kết giữa máy chủ với máy chủ hoặc máy khách đến máy chủ. Áp dụng cho một quy tắc tường lửa hiện đang phải chịu một khoảng thời gian chờ đợi bốn đến sáu tuần. Giảm số lượng quy tắc tường lửa sẽ giảm áp lực cho nhóm bảo mật mạng.

Cấu hình IP máy chủ SQL

Việc định cấu hình phiên bản SQL Server để chỉ nhận trên một IP chuyên dụng và cổng được thực hiện bằng cách sửa đổi một số cài đặt trong tiện ích Trình quản lý cấu hình máy chủ SQL. Bước đầu tiên là khởi động Trình quản lý cấu hình máy chủ SQL và trong phần bên trái, chọn Cấu hình mạng máy chủ SQL | Giao thức cho InstanceName . Trong ngăn bên trái, nhấp chuột trái vào Tên giao thức TCP / IPKích hoạt giao thức. Sau đó nhấp chuột trái vào giao thức một lần nữa và hiển thị cửa sổ Thuộc tính cho TCP / IP .

Sau đó, đảm bảo các cài đặt sau được đặt trong thanh ghi Giao thức :

Enabled           : Yes
Listen All        : No

Trong đăng ký Địa chỉ IP, hãy kiểm tra các cài đặt sau cho địa chỉ IP được đề cập (ví dụ: đối với máy chủ Dịch vụ báo cáo trong ví dụ này, nó sẽ dành cho 168.xxx.xxx.71)

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

Lưu ý: Điều quan trọng là cài đặt cho Cổng động TCP trống không chỉ là 0 (không).

Bây giờ bạn có một phiên bản SQL Server sẽ chỉ nhận các kết nối cơ sở dữ liệu trên 168.xxx.xxx.71 bằng cổng 1433.

Tóm tắt sơ thẩm máy chủ SQL

Dịch vụ Trình duyệt Máy chủ SQL không chạy và mỗi phiên bản SQL Server riêng lẻ được định cấu hình để chỉ sử dụng địa chỉ IP của chính nó trên cổng 1433. Cho một phiên bản SQL Server có tên GENITH, một máy chủ Windows có tên máy chủ SQLSERVER01 và hai địa chỉ IP 162.xxx .xxx.50 (máy chủ) và 162.xxx.xxx.51 (Trường hợp SQL) Tôi sẽ kết thúc với các mục cấu hình sau:

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

Máy chủ SQL sẽ không nhận các yêu cầu cho 162.xxx.xxx.50: 1433, vì không có phiên bản SQL Server nào được cấu hình để nghe trên địa chỉ IP này trong tiện ích Trình quản lý cấu hình SQL Server. Máy chủ SQL sẽ chỉ nhận các yêu cầu cho SQLSERVER01-i01 (trên cổng 1433) hoặc 162.xxx.xxx.51,1433.

Tóm tắt sơ thẩm dịch vụ báo cáo máy chủ SQL

Dịch vụ Trình duyệt Máy chủ SQL không chạy và mỗi phiên bản Dịch vụ Báo cáo Máy chủ SQL riêng lẻ được định cấu hình để chỉ sử dụng địa chỉ IP của chính nó trên cổng 1433. Đưa ra một phiên bản Dịch vụ Báo cáo Máy chủ SQL có tên GENITH, máy chủ Windows có tên máy chủ SQLSERVERRS01, một ứng dụng trên SSRS có tên APPL1và hai địa chỉ IP 168.xxx.xxx, 70 (máy chủ) và 168.xxx.xxx.71 (Trường hợp SQL) Tôi sẽ kết thúc với các mục cấu hình sau:

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

Máy chủ SQL sẽ không nhận các yêu cầu cho 168.xxx.xxx, 70: 1433, vì không có phiên bản SQL Server nào được cấu hình để nghe trên địa chỉ IP này trong tiện ích Trình quản lý cấu hình SQL Server. Máy chủ SQL sẽ chỉ nhận các yêu cầu cho SQLSERVER01-i01 (trên cổng 1433) hoặc 162.xxx.xxx.71,1433.

SSRS sẽ nhận các yêu cầu cho http: // sqlserverrs01-i01 / báo cáo_APPL1 hoặc http: // sqlserverrs01 / báo cáo_APPL1 vì cấu hình *: 80 trong Cấu hình dịch vụ báo cáo cho tiêu đề máy chủ.

Tôi hy vọng tôi đã cung cấp đủ thông tin cho bất kỳ ai sẵn sàng dành thời gian để viết câu trả lời và tôi mong muốn các chi tiết và liên kết kỹ thuật của bạn.

Được viết bằng StackEdit và sau đó được sửa đổi thủ công để tương thích stackexchange.

Lịch sử

Chỉnh sửa 1 : Bản phát hành ban đầu
Chỉnh sửa 2 : Định dạng lại để dễ đọc. Đã giải thích SF / DB xuống. Đã thêm tên máy chủ cho Windows Server
Chỉnh sửa 3 : Đã sửa lỗi địa chỉ IP sai trong danh sách quy tắc tường lửa.
Chỉnh sửa 4 : đã thay đổi lưu trữ từ thành chạy (đó là môi trường không ảo hóa) ở một số nơi. Đã thêm địa chỉ IP trong một câu
Chỉnh sửa 5 : Đã thêm danh sách các bài viết tôi đã tham khảo và hỗ trợ tham khảo
Chỉnh sửa 6 : Làm sạch phần Lịch sử


1
Tôi nghĩ rằng nếu bạn có thể giải quyết nó ở mức thấp hơn trong ngăn xếp mạng, thì máy khách SSRS và SQL Native không nên bị làm phiền bởi nó. Ví dụ: nếu bạn có thể thêm một tuyến đường đến phiên bản SQL Server của mình trên máy chủ SSRS để luôn sử dụng một NIC cụ thể mà bạn có thể thoát khỏi nó
Tom V - hãy thử topanswers.xyz

1
Nếu tôi nhớ chính xác, IP chuyên dụng cho SSRS chỉ đơn giản là một ràng buộc IIS (các báo cáo về cơ bản là một trang IIS ưa thích) và không được sử dụng để liên lạc. Tôi không có cách nào để kiểm tra lý thuyết của mình nhưng tôi không tin SSRS sẽ giao tiếp với các nguồn dữ liệu của SQL Server qua IP chuyên dụng của nó.
Nathan C

Câu trả lời:


6

Giới thiệu

Theo các tài liệu khác nhau tôi tìm thấy trong quá trình nghiên cứu ban đầu của tôi và các tài liệu được cung cấp trong các liên kết và thảo luận tôi đã đưa ra một giải pháp phù hợp, đáng tin cậy, phù hợp.

RFC 3484

Các so sánh nhị phân được tiến hành sâu hơn và các quy tắc được áp dụng theo RFC 3484 , điều này rõ ràng cũng hợp lệ đối với các địa chỉ IPv4.

RFC 3484 cũng tuyên bố ngay sau Quy tắc 8 rằng

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.

Lựa chọn địa chỉ IP nguồn trên máy tính Windows nhiều Homed

Bây giờ không phải tất cả các quy tắc trong RFC 3484 áp dụng cho các địa chỉ IPv4. Bài viết Microsoft Blog Nguồn lựa chọn địa chỉ IP trên Máy tính Windows nhiều Homed giải thích quy tắc nào được áp dụng.

Có một phần nhỏ ngay bên dưới Hành vi Windows Vista / Windows Server 2008 có nội dung:

Tương tự như XP khi chương trình không chỉ định IP nguồn, ngăn xếp tham chiếu địa chỉ IP đích, sau đó kiểm tra toàn bộ bảng tuyến IP để có thể chọn bộ điều hợp mạng tốt nhất để gửi gói. Sau khi bộ điều hợp mạng được chọn, ngăn xếp sử dụng quy trình chọn địa chỉ được xác định trong RFC 3484 và sử dụng địa chỉ IP đó làm địa chỉ IP nguồn cho các gói tin đi.

Xem như tôi chỉ có một NIC trong phiên bản SQL / SSRS, phần đầu tiên là moot. Windows Server sẽ luôn chọn NIC duy nhất khả dụng.

Cho đến nay, việc kết hợp RFC 3484 với Microsoft Blog cho kết quả cả hai địa chỉ IP là ứng cử viên hợp lệ cho địa chỉ IP nguồn. Các giải thích tiếp theo xuống trong câu trả lời.

Người cáp

Một bài viết từ Cáp Guy Mô hình máy chủ mạnh và yếu của cáp Guy đi sâu vào chi tiết hơn về cách lựa chọn IP hoạt động trong môi trường Gửi và nhận máy chủ mạnh và trong môi trường Gửi và nhận máy chủ yếu . Đọc thêm tốt, nhưng không làm sáng tỏ thêm về cách chọn IP nguồn. Bài viết liên quan đến RFC 3484 đã được biết đến.

Giải thích điều không thể giải thích

Để giải thích giải pháp, trước tiên chúng tôi phải chuyển đổi các địa chỉ IP được đề cập thành tương đương nhị phân của chúng. Thấy rằng tôi không cung cấp cổng thông tin trong câu hỏi của mình, tôi sẽ giả sử hai giá trị.

Địa chỉ IP nguồn và ký hiệu nhị phân

Dưới đây là danh sách các giá trị nhị phân được chuyển đổi cho các địa chỉ IP liên quan.

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

Địa chỉ IP đích và ký hiệu nhị phân

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

Ví dụ 1: IP Gateway thấp hơn IP Instance SQL / SSRS

Trong ví dụ này tôi sẽ giả sử rằng địa chỉ IP của cổng thấp hơn địa chỉ IP của phiên bản SQL Server / SSRS, cụ thể là 168.001.001.002.

Nếu bạn so sánh cả hai địa chỉ nhị phân của phiên bản Windows Server và SQL Server / SSRS, thì bạn có các thông tin sau:

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)

Kết quả Ví dụ 1

Trong ví dụ này, cả hai địa chỉ IP đều có cùng số lượng bit thứ tự cao phù hợp (hoặc tiền tố phù hợp dài nhất). Cho đến bây giờ, quá trình http.sys sẽ sử dụng một trong hai địa chỉ IP để liên lạc đi.

Ví dụ 2: IP Gateway cao hơn IP Instance SQL / SSRS

Trong ví dụ này tôi sẽ giả sử rằng địa chỉ IP của cổng cao hơn địa chỉ IP của phiên bản SQL Server / SSRS, cụ thể là 168.001.001.100.

Nếu bạn so sánh cả hai địa chỉ nhị phân của phiên bản Windows Server và SQL Server / SSRS, thì bạn có các thông tin sau:

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)

Kết quả Ví dụ 2

Mặc dù địa chỉ IP của cổng hiện cao hơn địa chỉ IP của máy chủ Windows và phiên bản SQL / SSRS, lượng bit khớp thứ tự cao (hoặc tiền tố khớp dài nhất) vẫn giống nhau. Cho đến bây giờ, quá trình http.sys sẽ sử dụng một trong hai địa chỉ IP để liên lạc đi.

Tóm tắt các kết quả cho đến nay

Cho đến nay, không thể biết địa chỉ IP nào mà quá trình http.sys sẽ sử dụng cho các giao tiếp gửi đi chạy trên phiên bản SQL / SSRS (.71) trên máy chủ windows (.70).

"Khi bạn đã loại bỏ những điều không thể, bất cứ điều gì còn lại, dù không thể xảy ra, đều phải là sự thật" - Sherlock Holmes

Có những tình huống mà địa chỉ IP nguồn chắc chắn có thể được xác định chính xác / được chọn / xác định với kiến ​​thức RFC và Microsoft đã nói ở trên. Nhưng nếu các địa chỉ IP quá gần nhau và gần cổng, thì tất cả chỉ là may mắn. Hoặc là nó?

Thấy tôi đang ở vị trí thực hiện các quy tắc (tường lửa) và Microsoft có ...

triển khai (đó) có các phương tiện lựa chọn khác trong số các địa chỉ nguồn. Ví dụ: nếu việc triển khai bằng cách nào đó biết địa chỉ nguồn nào sẽ dẫn đến hiệu suất truyền thông "tốt nhất".

... Sau đó, tất cả những gì tôi phải làm để xác định địa chỉ IP của quy trình http.sys là chỉ tạo một quy tắc tường lửa với địa chỉ IP mong muốn.

Chuyện gì xảy ra

  1. Tôi xác định quy tắc tường lửa từ 168.xxx.xxx.71 đến 168.xxx.xxx.51: 1433
  2. Thành phần http.sys của phiên bản SQL / SSRS tuân thủ RFC 3484 và chọn IP nguồn theo các quy tắc được xác định
  3. Địa chỉ IP 168.xxx.xxx.71 (trên NIC1) được xác định là địa chỉ IP nguồn để đến địa chỉ IP 168.xxx.xxx.51 qua cổng 1433 và do đó được gán cho tất cả các gói đi

Những lợi ích

  1. Tôi không có cách nào can thiệp vào việc thực hiện RFC 3484
  2. Tôi không có cách nào để tung hứng với các tuyến đường hoặc cấu hình ARP
  3. Tôi tuân thủ RFC 3484 và triển khai của Microsoft
  4. Tôi không hack bất kỳ cài đặt đăng ký hoặc cấu hình hệ thống
  5. TÔI CÓ MỘT BÀI HÁT HẤP DẪN

xác minh

Tôi vẫn chưa xóa địa chỉ IP khỏi các quy tắc tường lửa, nhưng tôi tự tin rằng nó sẽ hoạt động như được thiết kế / xác định. Một bản tóm tắt sẽ làm theo.

Lịch sử

Chỉnh sửa 1 Bài đăng ban đầu
Chỉnh sửa 2 Làm sạch câu trả lời, thêm phần Lịch sử


1
Logic của bạn có vẻ hợp lý và rõ ràng bạn đã nỗ lực đáng kể để xác định hành vi hiện tại. Tuy nhiên, việc dựa vào một chi tiết triển khai là nguy hiểm vì không có gì đảm bảo nó sẽ không thay đổi mà không cần thông báo trước.
Jens Ehrich

Chúng ta có thể cùng nhau đồng ý về "phá vỡ bởi thiết kế"? Tôi đồng ý rằng tôi đang dựa vào RFC 3484 và việc triển khai của Microsoft, nhưng tôi có những lựa chọn nào khác? Tôi có nên tuân thủ các quy tắc tường lửa kép để ở bên an toàn không?
John aka hot2use

1
Có, hai quy tắc là lựa chọn an toàn duy nhất. Tôi hoàn toàn đồng ý rằng nó không được thực hiện đúng, cũng không tốt lắm.
Jens Ehrich

4

SSRS hỗ trợ một số nguồn dữ liệu tiêu chuẩn cũng như các nguồn dữ liệu .NET khác:

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

Giả sử bạn đang sử dụng máy khách gốc SQL cho nguồn dữ liệu, bạn không có tùy chọn để chỉ định địa chỉ IP nguồn:

https://msdn.microsoft.com/en-us/l Library / system.data.sqlclient.sqlconnection.connection chuỗi (v = vs.110) .aspx

Do đó, lý do là máy khách sẽ sử dụng IPADDR_ANY trong phương thức Bind () khi thiết lập kết nối mạng. Điều này khiến Windows đưa ra quyết định.

Windows 2008 và lựa chọn địa chỉ lên dựa trên số bit phù hợp cao nhất với bước nhảy tiếp theo có nghĩa là câu trả lời phụ thuộc vào cổng mặc định của bạn (hoặc bất kỳ tuyến đường cụ thể nào bạn có thể đã xác định).

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

Tôi không thấy bất kỳ đề cập nào về các tuyến đường hoặc cổng trong sơ đồ của bạn để tôi có thể nhận được.

Chúc may mắn!


Bạn có thể giả sử 168.xxx.xxx.002 hoặc là 168.xxx.xxx.100 làm cổng mặc định. Nó không có tác động gì đến quá trình lựa chọn IP. Cả hai địa chỉ IP .70 và .71 đều có cùng tiền tố dài nhất .
John aka hot2use

Vì nó không rõ ràng, bạn có thể sử dụng Skipassource ( blog.technet.microsoft.com/rmilne/2012/02/08/ Ấn ), tuy nhiên điều đó sẽ ảnh hưởng đến tất cả lưu lượng truy cập đi. Nếu không, bạn sẽ phải tạo cả hai quy tắc b / c không có gì đảm bảo cả; ngay cả khi hệ thống luôn chọn cùng một IP ngay bây giờ, các bản cập nhật trong tương lai có thể phá vỡ cấu hình của bạn.
Jens Ehrich

Tôi đã đọc về tham số SKIPASSOURCE trong bài viết và đi đến kết luận rằng nó có thể bị xóa trong phiên bản tương lai của việc triển khai IP, bởi vì nó được giới thiệu với một hotfix.
John aka hot2use

1
Theo kinh nghiệm của tôi (hơn 20 năm) các hotfix thường được sử dụng để (1) nhanh chóng cung cấp bản sửa lỗi chưa được kiểm tra đầy đủ hoặc (2) cung cấp bản sửa lỗi tạm thời để phát triển giải pháp vĩnh viễn. Dù bằng cách nào tôi cũng không mong họ loại bỏ khả năng này. Tuy nhiên, nó có thể ảnh hưởng tiêu cực đến phần còn lại của cấu hình của bạn, bạn sẽ phải điều chỉnh tất cả các quy tắc tường lửa khác.
Jens Ehrich
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.