你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

在虚拟 WAN 中使用专用链接

项目
10/15/2024

Azure 专用链接技术可用于通过公开专用终结点，使用专用 IP 地址连接来连接 Azure 平台即服务产品。使用 Azure 虚拟 WAN，可以在一个连接到任何虚拟中心的虚拟网络中部署专用终结点。此专用链接提供了与连接到同一虚拟网络的任何其他虚拟 WAN 或分支的连接。

开始之前

本文中的步骤假设你已部署了具有一个或多个中心的虚拟 WAN，并且至少有两个虚拟网络连接到虚拟 WAN。

若要创建新虚拟 WAN 和新中心，请使用以下文章中的步骤：

虚拟 WAN 中专用链接的路由注意事项

Azure 中的专用终结点连接是监控状态的。通过虚拟 WAN 建立与专用终结点的连接时，流量通过不同的虚拟 WAN 组件（例如虚拟中心路由器、ExpressRoute 网关、VPN 网关、Azure 防火墙或 NVA）经由一个或多个流量跃点进行路由。流量的确切跃点基于虚拟 WAN 路由配置。在后台，Azure 软件定义的网络层将与单个 5 元组流相关的所有包发送到为不同虚拟 WAN 组件提供服务的后端实例之一。 Azure 平台不支持非对称路由流量（例如，与路由到不同后端实例的单个 5 元组流对应的流量），并会将其丢弃。

在虚拟 WAN 基础结构上的维护事件期间，后端实例会逐个重启，这可能会导致专用终结点出现间歇性连接问题，原因是为流提供服务的实例暂时不可用。当 Azure 防火墙或虚拟中心路由器横向扩展时，可能会出现类似问题。同一流量流可以与一个新的后端实例负载均衡，而该后端实例不同于与当前为流提供服务的实例。

要缓解维护和横向扩展事件对专用链接或专用终结点流量的影响，请考虑以下最佳做法：

将本地应用程序的 TCP 超时值配置为 15-30 秒之间。较小的 TCP 超时值可让应用程序流量更快地从维护和横向扩展事件中恢复。或者，测试不同的应用程序超时值，根据要求确定合适的超时值。
预先缩放虚拟 WAN 组件以处理流量突发，防止发生自动缩放事件。对于虚拟中心路由器，可以在中心路由器上设置最小路由基础结构单元，以防止在流量突发期间进行缩放。

最后，如果使用 VPN 或 ExpressRoute 在 Azure 与本地之间进行本地连接，请确保本地设备配置为使用相同的 VPN 隧道或相同的 Microsoft Enterprise Edge 路由器，作为与专用终结点流量对应的每个 5 元组的下一个跃点。

创建专用链接终结点

可以为许多不同服务创建专用链接终结点。在此示例中，我们使用 Azure SQL 数据库。有关如何为 Azure SQL 数据库创建专用终结点的详细信息，请参阅快速入门：使用 Azure 门户创建专用终结点。下图显示了 Azure SQL 数据库的网络配置：

创建 Azure SQL 数据库之后，可以通过浏览专用终结点来验证专用终结点 IP 地址：

单击已创建的专用终结点，应该会看到其专用 IP 地址和完全限定的域名 (FQDN)。专用终结点的 IP 地址应在 VNet 范围 (10.1.3.0/24) 内：

验证来自同一 VNet 的连接

在此示例中，我们验证了从安装了 MS SQL 工具的 Linux 虚拟机到 Azure SQL 数据库的连接。第一步是验证 DNS 解析是否有效，以及 Azure SQL 数据库完全限定的域名是否在部署了专用终结点的同一 VNet (10.1.3.0/24) 中解析为了专用 IP 地址：

nslookup wantest.database.windows.net

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
wantest.database.windows.net    canonical name = wantest.privatelink.database.windows.net.
Name:   wantest.privatelink.database.windows.net
Address: 10.1.3.228

如前面的输出中所示，FQDN wantest.database.windows.net 映射到了 wantest.privatelink.database.windows.net，随专用终结点一起创建的专用 DNS 区域将解析为专用 IP 地址 10.1.3.228。可通过查看专用 DNS 区域来确认已将专用终结点的 A 记录映射到了专用 IP 地址：

验证正确的 DNS 解析后，可以尝试连接到数据库：

query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"

10.1.3.75

如你所见，我们使用的是一个特殊的 SQL 查询，该查询提供了 SQL 服务器从客户端看到的源 IP 地址。在这种情况下，服务器会看到具有其专用 IP (10.1.3.75) 的客户端，这意味着流量从 VNet 直接流入专用终结点。

将变量 username 和 password 设置为与在 Azure SQL 数据库中定义的凭据匹配的值，从而使本指南中的示例生效。

从其他 VNet 连接

既然 Azure 虚拟 WAN 中的一个 VNet 可以连接到专用终结点，那么连接到虚拟 WAN 的所有其他 VNet 和分支就也可以访问该终结点。你需要通过 Azure 虚拟 WAN 支持的任何模型（举两个例子，任意连接性方案或共享服务 VNet 方案）提供连接。

在 VNet 或分支与已部署专用终结点的 VNet 之间建立连接后，需要配置 DNS 解析：

如果从 VNet 连接到专用终结点，则可以使用通过 Azure SQL 数据库创建的同一专用区域。
如果从分支（站点到站点 VPN、点到站点 VPN 或 ExpressRoute）连接到专用终结点，则需要使用本地 DNS 解析。

在此示例中，我们从其他 VNet 进行连接。首先将专用 DNS 区域附加到这个新的 VNet，使其工作负载能够将 Azure SQL 数据库完全限定的域名解析为专用 IP 地址。此操作通过将专用 DNS 区域链接到新的 VNet 来完成：

现在，附加 VNet 中的任何虚拟机都应将 Azure SQL 数据库 FQDN 正确解析为专用链接的专用 IP 地址：

nslookup wantest.database.windows.net

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
wantest.database.windows.net    canonical name = wantest.privatelink.database.windows.net.
Name:   wantest.privatelink.database.windows.net
Address: 10.1.3.228

为了再次检查此 VNet (10.1.1.0/24) 是否已连接到配置了专用终结点的原始 VNet (10.1.3.0/24)，可以验证 VNet 中任何虚拟机中的有效路由表：

如你所见，有一个路由指向由 Azure 虚拟 WAN 中的虚拟网络网关注入的 VNet 10.1.3.0/24。现在，我们终于可以测试与数据库的连接了：

query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"

10.1.1.75

在此示例中，我们已了解如何在附加到虚拟 WAN 的一个 VNet 中创建专用终结点，从而提供与虚拟 WAN 中其余 VNet 和分支的连接。

后续步骤

有关虚拟 WAN 的详细信息，请参阅常见问题解答。

通过