☰

简要回答

tag-icon • tag-icon azure-networking
简要回答

看看下面的内容： 在此处输入图片描述

这里我们看到一个 AZURE 公司帐户 X。请参阅“azsql1.database.windows.net”。您可以从本地访问它。

如果为了参数的缘故，我有第二个 AZURE 环境，配置完全相同 - AZURE 公司帐户 Y，带有“azsql1.database.windows.net”。

这是理论上的，但我想知道如果有人尝试在 Tableau、Spotfire 等中使用“azsql1.database.windows.net”进行连接报告，本地如何解决这个问题？

我推测您需要以某种方式告知在哪个 AZURE 公司帐户中使用哪个 DNS 转发器。

所以，请原谅我，但我了解互联网等的基本 DNS 解析内容，但不是网络专家。

答案1

对于有同样问题的其他读者：另请参阅用于从本地访问 AZURE 资源的私有 IP 地址的地址了解一些背景信息。

在我开始回答你的问题之前，我要对你的问题做一个小小的更正，因为你写的是“...相同的 DNS 名称”。我认为这是一种误解，因为Azure Cosmos DB是一项完全托管的服务，意味着平台即服务 (PaaS)因此具有唯一的名称。换句话说，两个 Azure Cosmos DB 服务不可能具有相同的 DNS 名称。不过，我不想在问题中纠正这一点，而是希望将引用作为答案的一部分，因为这确实是一个常见的误解。这一切都归结为混合解决方案的名称解析的架构方式。

解决这种情况很容易，只需使用唯一的 DNS 名称（这不是问题，因为 CosmosDB 是 SaaS，因此具有唯一的名称）并确保可以解析所有资源。

简要回答

对于通过 ExpressRoute 或 VPN 连接到本地的企业帐户下的每个订阅，请配置Azure 专用 DNS以及部署在同一子网内的 DNS 转发器。Hub 连接一切，包括本地。

长答案

假设示例（任务定义）

最好用一个例子来解释其工作原理。

假设企业“北约克特INC”有3个部门：

  • 金融
  • 它
  • 营销

每个部门运营 2 个 Azure 订阅，一个用于开发，另一个用于生产工作量。因此，我们总共必须处理至少 6 个订阅才能满足要求。

与网络相关的要求如下：

  • 每个订阅都需要与本地连接。
  • 每个订阅可能会或可能不会使用通过私有链接部署的资源。
  • 由于法律限制，所有订阅内的所有资源目前均部署在地区“美国东部”。
  • 计划扩展业务，最终覆盖其他地区。因此，在规划中应考虑到这一点。

实施方法

使用此方案，您最终可能会获得至少 7 个订阅：

  • 发展金融
  • prd 财务
  • 开发它
  • prd-它
  • 开发营销
  • 市场营销
  • 中心通过 VPN 或 ExpressRoute 连接到内部部署。

所有六个订阅都需要部署 Azure 私有 DNS 和 DNS 转发器。此外，它们都使用与中央 Hub 订阅对等的 VNET。因此，最终您将获得以下七个内部 DNS 域：

  • 开发人员.finance.eastus.azure.nkotb
  • prd.finance.eastus.azure.nkotb
  • 开发者.it.eastus.azure.nkotb
  • 微软Azure.nkotb
  • 开发者.marketing.eastus.azure.nkotb
  • 营销.eastus.azure.nkotb
  • 中心.eastus.azure.nkotb

NKOTB inc - 高级网络连接概述

Hub 订阅配置了第二组 DNS 服务器和转发器。只有这组 DNS 服务器知道部署在其他域中的其他七个 DNS 转发器，并负责域“eastus.azure.nkotb”的名称解析。所有本地 DNS 服务器都配置为将所有对 *.eastus.azure.nkotb 的 DNS 请求转发到这组 DNS 服务器。

示例 1：订阅和本地之间的内部 DNS

假设财务团队决定使用私有链接在生产订阅中部署名为“Alzheimer”的数据库。因此，此数据库的内部 DNS 名称 (FQDN) 将是alzheimer.prd.finance.eastus.azure.nkotb。由于内部名称解析与所有订阅以及本地一致，因此此名称可以在公司网络的任何地方解析。

示例 1 的工作原理

  • 位于本地的随机客户端正在请求本地 DNS 服务器解析alzheimer.prd.finance.eastus.azure.nkotb。
  • 本地 DNS 服务器不知道答案，但配置为将所有请求转发*.eastus.azure.nkotb到部署在 Hub 订阅中的 DNS 转发器，因此他会知道答案。此 DNS 服务器是可访问的（网络方面），因为本地通过 ExpressRoute/VPN 连接到此 Hub 订阅。
  • 部署在中心订阅内的 DNS 转发器不知道答案，但知道部署在生产财务订阅中的 DNS 转发器，因此请求会朝这个方向转发。此 DNS 服务器是可访问的（从网络角度而言），因为两个订阅都具有对等 VNET。
  • prd.finance.eastus.azure.nkotb 中部署的 DNS 服务器和转发器可以解析数据库的 IP 地址，并将答案发回链中。
  • 位于现场的客户端收到答复。
  • 每个后续 DNS 请求（在记录的 TTL 内）将立即从本地 DNS 服务器得到答复，因为答案已被缓存。

示例 2：两个订阅之间的内部 DNS

鉴于营销团队决定在开发订阅中部署一个名为“Ballyhoo”的数据库，因此内部 DNS 名称将是ballyhoo.dev.marketing.eastus.azure.nkotb。与财务部署的另一个数据库一样，此数据库也可以从本地解析。但在这种情况下，IT 团队在 IT 开发订阅中收集一些数据，这些数据应使用ballyhoo.dev.marketing.eastus.azure.nkotb数据库进行存储。因此，此场景描述了如何在 2 个订阅中解析 DNS 记录。

示例 2 的工作原理

  • 部署在 dev-IT 订阅中的数据收集应用程序向部署在同一 VNET 内的本地 DNS 解析器请求 的 IP 地址 ballyhoo.dev.marketing.eastus.azure.nkotb。
  • 本地 DNS 服务器不知道答案，但配置为将所有请求转发到部署在 Hub 订阅中的 DNS 转发器，因此他会这样做。此 DNS 服务器是可访问的（从网络角度而言），因为两个订阅都具有对等 VNET。
  • 部署在中心订阅内的 DNS 转发器不知道答案，但知道部署在开发营销订阅中的 DNS 转发器，因此请求会朝这个方向转发。此 DNS 服务器是可访问的（从网络角度而言），因为两个订阅都具有对等 VNET。
  • 部署在 dev.marketing.eastus.azure.nkotb 中的 DNS 服务器和转发器可以解析数据库的 IP 地址，并将答案发回链中。
  • 数据收集应用程序接收答案。
  • 每个后续 DNS 请求（在记录的 TTL 内）将立即从本地 DNS 服务器得到答复，因为答案已被缓存。

笔记

您在 Azure 的业务联系人通常会帮助规划此类场景，因此您不必自己解决所有问题。在规划过程中还需要考虑其他重要方面，但由于篇幅有限，这里无法一一列举。认识：如果从一开始就让网络团队参与到流程中，通常会有所帮助。

总的来说，我强烈建议使用免费的适用于 Azure 的 Microsoft Learn积累必要的知识和技能。对于您的问题，以下课程就足够了：

相关内容