☰

太长了

tag-icon • tag-icon sql-server firewall windows-server-2012-r2 ip ssrs
太长了

太长了

我在多实例 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.xxx.xxx.70）的另一个 Windows 服务器（SQLSERVERRS01）上运行。

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

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

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

问题

（根据下面的屏幕截图）

当 Reporting Services 服务器连接到 SQL Server 实例（在 162.xxx.xxx.51 上）以检索数据时，它是否总是与运行 SSRS 的 Windows 服务器（168.xxx.xxx.70 / 首选）的底层 IP 地址建立连接，或者它（有时）会使用 SQL Server Reporting Services 实例（168.xxx.xxx.71）的 IP 地址？

这与使用 IP 到 IP 方法配置防火墙规则有关。我要么必须申请一条规则，定义通过端口 1433 建立 168.xxx.xxx.71 到 162.xxx.xxx.51 的连接，要么申请一条规则，定义通过端口 1433 建立 168.xxx.xxx.70 到 162.xxx.xxx.51 的连接。

目前，我会申请这两条防火墙规则。

奖励问题

我可以配置 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 中的相应功能不同

第 5 和第 6 篇文章由詹姆士(dba.se)。目前看来，这些答案是最合适的。不过，我有点怀疑，一篇文章提到了使用多个 NIC，而我只有一个 NIC，并为其分配了多个 IP。汤姆(dba.se) 也提出了建议和一般评论。

为什么在这里而不是在 dba.stackexchange.com

由于问题的复杂性，我起初不愿意在 serverfault.com 上发布这个问题。这个问题既倾向于特定于 SQL Server，也倾向于特定于 Windows Server。最终我决定在这里发布它，因为我认为这是 Windows Server IP 处理问题（找不到更好的词了）。

如果版主认为我会在 dba.stackexchange.com 上得到更好的回应，那么请将问题移到那里。

详细解释

在我们的环境中，我们有托管多个 SQL Server 实例和多个 IP 设置的 Windows 服务器。我们添加了复杂的防火墙配置、专用的 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 网络配置 | 协议实例名称. 在左侧窗格中左键单击TCP/IP协议名称和使能够协议。然后再次左键单击该协议并调出TCP/IP 的属性窗户。

然后确保在协议登记：

Enabled           : Yes
Listen All        : No

在里面IP 地址检查以下有关 IP 地址的设置（例如，本例中的 Reporting Services 服务器的 IP 地址为 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 实例、一个主机名为 SQLSERVER01 的 Windows 服务器以及两个 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 Browser 服务未运行，并且每个单独的 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_APPL1或者http://sqlserverrs01/Reports_APPL1因为主机头的 Reporting Services 配置中的 *:80 配置。

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

写与堆栈编辑后来手动修改为与 stackexchange 兼容。

历史

编辑1： 初始发行
编辑2：重新格式化以提高可读性。将 SF / DB 说明向下移动。添加了 Windows Server 的主机名
编辑3：修复防火墙规则列表中错误的IP地址。
编辑4：在某些地方将托管一词改为运行（这是非虚拟化环境）。在一句话中添加了 IP 地址
编辑5：添加了我已经查阅和参考支持的文章列表
编辑6：清理历史部分

答案1

介绍

根据我在初步研究中找到的各种文档以及链接和讨论中提供的文档，我提出了一个可靠、合规的解决方案。

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 博客相结合，可以得出两个 IP 地址都是源 IP 地址的有效候选。解释在答案的后面。

电缆工

来自 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) 上运行的传出通信。

“当你排除了所有不可能的因素后，剩下的，无论多么不可思议，都一定是真相。”——夏洛克·福尔摩斯

在某些情况下，可以使用上述 RFC 和 Microsoft 知识来精确定位/选择/定义源 IP 地址。但如果 IP 地址彼此距离太近且靠近网关，那么一切都只能靠运气了。真的是这样吗？

鉴于我处于制定（防火墙）规则的位置并且微软有......

实现有其他方法来选择源地址。例如，如果实现以某种方式知道哪个源地址将产生“最佳”通信性能。

...然后我要做的就是确定 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整理答案，添加历史部分

答案2

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

因此，客户端在设置网络连接时，在 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/

我没有在您的图表中看到任何关于路线或网关的提及，所以我所能得到的就这么多。

祝你好运！

相关内容