多实例服务器上的SQL Server Reporting Services(SSRS)IP处理


9

Tl;博士

我在多实例SQL Server(Windows Server上的每个SQL Server实例都有其自己的IP地址)上有一个具有专用IP地址和端口(162.xxx.xxx.51:1433)的SQL Server实例(SQLSERVER01-i01) )都在一台Windows服务器(SQLSERVER01 / 162.xxx.xxx.50)上运行。

我还有一个专用的Reporting Services实例(SQLSERVERRS01-i01),具有其自己的IP地址和端口(168.xxx.xxx.71:1433),该实例在具有其IP地址(168)的其他Windows服务器(SQLSERVERRS01)上运行.xxx.xxx.70)。

专用的Reporting Services服务器具有一个应用程序APPL1,可以通过http://SQLSERVERRS01-i01:80/Reports_APPL1或通过来访问http://SQLSERVERRS01:80/Reports_APPL1

由于*:80Reporting Services配置中主机标头的配置,SSRS将同时接收这两个请求。

每个IP范围之间都有多个防火墙,这意味着我们必须为每个IP到IP或IPrange到IP连接申请特定的规则。但是,当涉及两台服务器时,安全性要求它始终必须是防火墙中的IP到IP规则。

(基于屏幕截图)

当Reporting Services服务器连接到SQL Server实例(位于162.xxx.xxx.51上)以检索数据时,它将始终与Windows服务器的基础IP地址(168.xxx.xxx.70 /首选)建立连接。 )表明SSRS正在运行,或者它(有时)会使用SQL Server Reporting Services实例的IP地址(168.xxx.xxx.71)?

这与使用IP到IP方法配置防火墙规则有关。我将必须申请一个规则,该规则定义通过端口1433连接168.xxx.xxx.71至162.xxx.xxx.51或通过端口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 Server安装
    基础文章中的安全注意事项

  2. 配置Windows防火墙以允许SQL Server访问
    本文指向有关SQL Server防火墙配置的所有其他文章。

  3. 为数据库引擎访问配置Windows防火墙
    使用任何IP地址。

  4. 为报告服务器访问配置防火墙
    正如本文所述,本文非常有趣:

    如果要访问外部计算机上的SQL Server关系数据库,或者报表服务器数据库位于外部SQL Server实例上,则必须在外部计算机上打开端口1433和1434。

    ...但是关于IP配置/设置/默认值仍然一言不发。

  5. 多宿主Windows计算机上的源IP地址选择

  6. Windows Server 2008和Windows Vista中用于源IP地址选择的功能与Windows早期版本中的相应功能不同

詹姆斯(dba.se)向我提供了第5条和第6条。目前,它们似乎是最合适的答案。但是,我有点怀疑是否有一篇文章提到使用多个NIC,而我只有一个分配了多个IP的NIC。汤姆(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在单个IP地址上最多运行15(十五)个SQL Server实例。这对于专用的Reporting Services实例同样有效。

防火墙规则

当前未将不同的IP范围未配置为区域,这意味着我们必须将每个防火墙规则分别配置为IP到IP或IPrange到IP规则。当涉及到两个服务器时,安全性要求它始终必须是IP到IP规则。每个SQL Server实例对于通信中涉及的防火墙都有自己的一套规则,这是服务器到服务器或客户端到服务器的链接。申请防火墙规则目前需要等待四到六周的时间。减少防火墙规则的数量将减少对网络安全团队的压力。

SQL Server实例IP配置

通过修改SQL Server配置管理器实用程序中的某些设置,可以将SQL Server实例配置为仅在专用IP和端口上进行拾取。第一步是启动SQL Server配置管理器,然后在左侧部分中选择“ SQL Server网络配置| SQL Server配置”。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动态端口的设置为空,而不仅仅是0(零)。

现在,您有了一个SQL Server实例,该实例将仅使用端口1433在168.xxx.xxx.71上拾取数据库连接。

SQL Server实例摘要

SQL Server Browser服务未运行,并且每个单独的SQL Server实例都配置为在端口1433上仅使用其自己的IP地址。给定名为GENERAL的SQL Server实例,这是一个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配置管理器实用程序中未将任何SQL Server实例配置为侦听此IP地址。SQL Server将仅接收对SQLSERVER01-i01(在端口1433上)或162.xxx.xxx.51,1433的请求。

SQL Server Reporting Services实例摘要

SQL Server浏览器服务未运行,并且每个单独的SQL Server Reporting Services实例都配置为仅在端口1433上使用其自己的IP地址。给定名为GENERAL的SQL Server Reporting Services实例,这是一台主机名为SQLSERVERRS01的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 Server将不会接收对168.xxx.xxx.70:1433的请求,因为在SQL Server配置管理器实用程序中未将任何SQL Server实例配置为侦听此IP地址。SQL Server将仅接收对SQLSERVER01-i01(在端口1433上)或162.xxx.xxx.71,1433的请求。

SSRS将为http:// sqlserverrs01-i01 / Reports_APPL1http:// sqlserverrs01 / Reports_APPL1提取请求,这是 因为Reporting Services配置中主机标头的*:80配置。

希望我能为愿意花时间写答案的任何人提供足够的信息,并期待您的技术细节和链接。

StackEdit编写,后来手动修改为与stackexchange兼容。

历史

编辑1:初始发行版
编辑2:重新格式化以提高可读性。下移说明SF / DB。为Windows Server
Edit 3添加了主机名:修复了防火墙规则列表中的错误IP地址。
编辑4:在某些地方将托管一词更改为正在运行(这是一个非虚拟环境)。在一次句子中添加了IP地址
编辑5:添加了我已经咨询并参考过的支持的文章列表
编辑6:清理历史记录部分


1
我认为,如果您可以在网络堆栈中的较低级别解决它,则SSRS和SQL Native Client不应该受到它的困扰。例如,如果您可以将一条路由添加到SSRS服务器上的SQL Server实例以始终使用特定的NIC,那么您可以摆脱它
Tom V-试试topanswers.xyz

1
如果我没记错的话,SSRS的专用IP只是一个IIS绑定(报告基本上是一个漂亮的IIS站点),并且不用于通信。我没有办法检验我的理论,但我不相信SSRS会通过其专用IP与SQL Server数据源进行通信。
内森·C

Answers:


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.

多宿主Windows计算机上的源IP地址选择

现在,并不是RFC 3484中的所有规则都适用于IPv4地址。Microsoft博客文章“ 多宿主Windows计算机上的源IP地址选择”介绍了适用哪些规则。

Windows Vista / Windows Server 2008行为的正下方有一小部分显示为:

与XP相似,当程序未指定源IP时,堆栈会引用目标IP地址,然后检查整个IP路由表,以便它可以选择发送数据包的最佳网络适配器。选择了网络适配器后,堆栈将使用RFC 3484中定义的地址选择过程,并将该IP地址用作出站数据包的源IP地址。

鉴于我在SQL / SSRS实例中只有一个NIC,所以第一部分没有任何意义。Windows Server将始终选择唯一可用的NIC。

到目前为止,将RFC 3484与Microsoft Blog结合使用会导致两个IP地址都是源IP地址的有效候选者。答案中的解释将继续下去。

电缆家伙

Cable Guy的文章《 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低于SQL / SSRS实例IP

在此示例中,我将假定网关的IP地址低于SQL Server / SSRS实例的IP地址,即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地址高于SQL Server / SSRS实例的IP地址,即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地址现在高于Windows服务器和SQL / SSRS实例的IP地址,匹配的高阶位(或最长匹配前缀)的数量仍然相同。到目前为止,http.sys进程将使用其中一个IP地址进行传出通信。

迄今为止的发现摘要

到目前为止,还无法确定http.sys进程将使用哪个IP地址进行Windows服务器(.70)上SQL / SSRS实例(.71)上运行的传出通信。

“当您消除了不可能的事情之后,无论多么不可能的事情,剩下的一切都必须成为事实”-Sherlock Holmes

在某些情况下,可以使用上述RFC和Microsoft知识明确指出/选择/定义源IP地址。但是,如果IP地址彼此之间以及网关之间太近,那么一切都太幸运了。还是?

看来我处于制定(防火墙)规则的位置,而Microsoft具有...

实现具有在源地址之间进行选择的其他方法。例如,如果实现以某种方式知道哪个源地址将导致“最佳”通信性能。

...那么确定http.sys进程的IP地址所需要做的就是仅创建一个具有所需IP地址的防火墙规则。

怎么了

  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上)被确定为通过端口1433到达IP地址168.xxx.xxx.51的源IP地址,因此被分配给所有传出数据包

好处

  1. 我绝不干扰RFC 3484的实施
  2. 我绝不玩弄路由或ARP配置
  3. 我符合RFC 3484和Microsoft的实施
  4. 我没有破解任何注册表设置或系统配置
  5. 我少了一个防火墙规则

验证

我尚未从防火墙规则中删除IP地址,但我相信它可以按设计/定义的方式工作。总结如下。

历史

编辑1初始发布
编辑2清理答案,添加了“历史记录”部分


1
您的逻辑似乎是合理的,并且您显然已经在确定当前行为方面付出了巨大的努力。但是,依靠实现细节是危险的,因为不能保证它不会在没有通知的情况下发生变化。
詹斯·埃里希

我们能否就“故意破坏”达成共识?我同意我依靠RFC 3484及其Microsoft的实现,但是我还有什么其他选择?为了安全起见,我应该坚持采用双重防火墙规则吗?
约翰aka hot2use

1
是的,只有两个规则是唯一安全的选择。我完全同意,它的实施不正确,也不是很好。
詹斯·埃里希

4

SSRS支持多个标准数据源以及其他.NET数据源:

https://msdn.microsoft.com/zh-CN/library/ms159219.aspx

假设您使用SQL本机客户端作为数据源,则没有选择指定源IP地址的选项:

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

因此,在建立网络连接时,在Bind()方法期间客户端将使用IPADDR_ANY是有理由的。这让Windows做出决定。

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选择过程没有任何影响。IP地址.70和.71具有相同的最长匹配前缀
约翰aka hot2use

由于模棱两可,您可以使用skipassource(blogs.technet.microsoft.com/rmilne/2012/02/08/…),但是这会影响所有传出流量。否则,您将不得不创建两个规则b / c,根本无法保证;即使系统现在总是选择相同的IP,将来的更新也可能会破坏您的配置。
詹斯·埃里希

我在文章中读到了SKIPASSOURCE参数并得出结论,因为它是随修补程序一起引入的,因此在IP实现的将来版本中可能会将其删除。
约翰aka hot2use

1
根据我的经验(超过20年),通常使用修补程序(1)快速提供尚未经过全面测试的修补程序,或者(2)提供将为其开发永久解决方案的临时修补程序。无论哪种方式,我都不希望他们删除此功能。但是,这可能会对您的配置b / c的其余部分产生负面影响,您必须调整所有其他防火墙规则。
詹斯·埃里希
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.