想象一下，你在云端构建了一个庞大而复杂的系统，通常我们会遵循最佳实践，将不同功能模块隔离在不同的网络区域中。比如，你可能有一个专门处理 Web 流量的网络，还有一个存放敏感数据库的后端网络。或者，你为了管理方便，将生产环境和测试环境分开了。这时候，一个棘手的问题就会出现：这两个被隔离的网络该如何安全、高效地互相通信呢？
在 Azure 的早期岁月里，如果我们想让两个虚拟网络（VNet）“对话”，不得不借助于 VPN 网关。这不仅需要额外的硬件配置，还会产生额外的费用，甚至可能因为流量流经公共互联网而带来性能瓶颈。但这显然不是我们在云端追求的“原生”体验。
在本文中，我们将深入探讨 Azure 虚拟网络对等互连。这是一种让虚拟网络之间通过 Azure 骨干网进行私密、低延迟通信的强大机制。我们会通过实际的场景，一步步演示如何配置它，并分享一些在实战中容易踩到的“坑”和优化技巧。
什么是 Azure 虚拟网络对等互连？
简单来说，虚拟网络对等互连就像是把两个不同的 Azure 虚拟网络“用一根网线”直接连在了一起。一旦对等互连建立成功，这两个网络中的资源（比如虚拟机、容器实例）就可以像在同一个局域网内一样，直接使用私有 IP 地址进行通信。
为了让你更直观地理解，我们可以这样对比：
- 没有对等互连：VNet A 和 VNet B 就像是两座孤岛，虽然它们都在 Azure 的海洋里，但想要通信，必须绕远路（通过 VPN 或公共 IP）。
- 有对等互连：我们在两座孤岛之间架起了一座横跨 Azure 骨干网的私有桥梁。流量不经过互联网，速度极快，且天然隔离。
#### 核心特性：非传递性
在我们深入配置之前，必须先理解一个对架构设计至关重要的概念：非传递性。
假设我们有三个虚拟网络：Prod-VNet（生产）、Dev-VNet（开发）和 QC-VNet（质量管控）。
- 我们将 Prod-VNet 与 Dev-VNet 进行了对等互连。
- 我们将 Dev-VNet 与 QC-VNet 进行了对等互连。
关键点来了： 这 并不意味着 Prod-VNet 和 QC-VNet 之间已经连通了。如果你想让 Prod 和 QC 通信，你必须显式地在它们之间也建立一个对等互连关系。这一点在设计网状网络拓扑时尤为重要，千万不要以为“朋友的朋友就是朋友”，在网络世界里，这行不通。
#### 支持的拓扑结构
利用对等互连，我们可以灵活地设计网络架构：
- 网状网络：所有的 VNet 之间都互相对等。这种结构冗余度高，但配置复杂度随节点数增加而指数级上升。
- 中心辐射型：这是最常见的企业级架构。我们创建一个中心的“枢纽 VNet”（通常存放 VPN/ER 网关、防火墙等共享服务），然后让其他“分支 VNet”（如生产、测试、各部门应用）分别与中心 VNet 对等互连。这样，分支之间虽然不直接相连，但可以通过中心的路由或防火墙进行受控的通信。
对等互连的类型与配置
根据你的业务需求，Azure 为我们提供了两种对等互连方式，理解它们的区别能帮你避免很多配置错误。
#### 1. 区域对等互连
这是最常用的场景。当两个虚拟网络位于相同的 Azure 区域（例如都在“东亚”区域）时，我们使用区域对等互连。流量不会离开该区域的数据中心，带宽极高，延迟极低。
#### 2. 全局 VNet 对等互连
当你的业务扩展到跨区域场景时（例如，Web 服务器在日本，数据库在巴西），我们可以使用全局对等互连。这允许跨 Azure 区域的标准 VNet 之间进行私密连接。虽然流量会经过区域之间的长距离链路，但它依然完全通过微软的全球骨干网传输，不会经过公共互联网。
#### 跨订阅与跨租户连接
Azure 的灵活性还体现在它打破了组织边界。我们不仅可以连接同一订阅下的 VNet，还可以跨订阅连接。更进一步，我们甚至可以跨 Azure AD 租户 建立对等互连。
- 实用见解：在跨租户配置时，你需要确保双方都有正确的权限，配置过程需要分别发起两次“握手”（一方发起，另一方接受）。这就像是建立外交关系，需要双方确认。
虚拟网络对等互连：实战指南
理论部分就到这里，让我们戴上手套，通过一个具体的例子来看看如何在 Azure 门户中实际操作。假设我们要搭建一个典型的“Web 层”和“数据库层”分离的架构。
#### 第 1 步：创建虚拟网络和定义地址空间
首先，我们需要确保你的网络地基打得牢。最常见的新手错误是IP 地址重叠。
- 场景：我们要创建 INLINECODE6aaed0b3 (10.1.0.0/16) 和 INLINECODEad69ce25 (10.2.0.0/16)。
操作流程：
- 登录到 Azure 门户。在搜索栏中输入“虚拟网络”，点击进入。
- 点击 “创建”。
- 在 “基本信息” 选项卡中：
* 选择你的资源组。
* 实例详情：命名为 INLINECODEab695b32。区域选择你离用户最近的区域（如 INLINECODE0c37f4d2）。
- 在 “IP 地址” 选项卡中（这是关键步骤）：
* 默认情况下 Azure 会分配一个 INLINECODEc55fc7b6 的地址空间。请务必修改它。我们将其修改为 INLINECODE74860ab9。
* 默认会有一个名为 INLINECODE02bd1e9e 的子网，范围自动设为 INLINECODE42036bdd。保持默认即可，或者根据你需要容纳的 VM 数量调整。
提示：在这个界面，你还可以看到一个“加密”选项。如果你对安全级别要求极高，可以勾选“启用虚拟网络加密”，这会使用底层基础设施来加密你的流量。*
- 点击 “查看 + 创建”，然后点击 “创建”。等待部署完成。
- 重复上述步骤，创建第二个虚拟网络 INLINECODE35a4d660，并将 IP 地址空间修改为 INLINECODE5020aeab。
> 重要提示：如果你尝试将两个地址空间均为 10.0.0.0/16 的网络进行对等互连，Azure 会直接报错。请在规划阶段就使用 Excel 或 Visio 管理好你的 IP 地址分配表（IPAM），以免后续返工。
#### 第 2 步：建立对等互连连接
现在地基已经打好，让我们来架桥。对等互连的配置是单向的，这意味着要建立双向通信，我们需要配置两次：从 A 到 B，以及从 B 到 A。
- 在 Azure 门户中找到并进入你刚才创建的
WebVNet。 - 在左侧菜单栏中，找到 “设置” 部分的 “对等互连”（Peering），点击进入。
- 在顶部的工具栏点击 “+ 添加” 按钮。
配置界面详解（这是你将看到的核心选项）：
- 此虚拟网络的名称：为了符合命名规范，建议使用类似
WebVNet-To-DbVNet的名称。这清楚地表明了流量方向。 - 流量转发：默认情况下，VNet 对等互连只允许两个网络中的资源互相通信。如果你的 INLINECODEbe42aa77 还有一个虚拟网络网关，并且你想让 INLINECODE52267467 的流量通过这个网关转发到其他地方（比如本地网络），你需要勾选 “允许网关传输”。在中心辐射型架构中，中心的 VNet 必须开启此选项，分支 VNet 才能通过中心访问本地数据中心。
- 远程虚拟网络：
* 部署模型：选择“资源管理器”。
* 我知道资源 ID：如果你记得 ID 可以直接填，但更简单的方法是点击 “选择一个虚拟网络”，然后在列表中选择 DbVNet。
- 远程对等互连名称：这是给对方（INLINECODEdf2104ee）看的连接名称。建议命名为 INLINECODE6fe61fd8。这样在对方的配置列表中看起来也很清晰。
#### 第 3 步：验证与测试
配置完成后，状态应该很快显示为 “已连接”。但这还不够，我们需要证明它真的在工作。
让我们来做一个简单的测试：
- 在 INLINECODE0fb8c871 的 INLINECODEf9d300cd 子网中创建一台 Windows VM（命名为
Web-VM）。 - 在 INLINECODE8e5a642d 的 INLINECODEf2508d3d 子网中创建一台 Linux VM（命名为
Db-VM）。 - 关键测试：登录到 INLINECODEce0feb70，打开命令提示符（CMD），尝试 ping INLINECODEdd2d527c 的私有 IP 地址（例如
ping 10.2.0.4）。
> 注意：Azure 默认会阻止来自互联网的 ICMP 流量，但在 VNet 内部，如果你只是为了测试连通性，请确保你的网络安全组（NSG）允许入站 ICMP 流量，或者简单地使用 PowerShell 的 Test-NetConnection 命令测试端口（如 RDP 3389 或 SSH 22），这通常比 ping 更可靠。
虚拟网络对等互连的优势
既然我们费了这么大劲配置它，它到底给我们带来了什么好处？让我们总结一下：
#### 1. 性能与低延迟
对等互连使用的是微软 Azure 的底层骨干网络。无论你是区域互联还是全球互联，流量都尽可能在微软的数据中心之间传输，而不是绕道公共互联网。这对于数据库同步、微服务调用等对延迟敏感的场景至关重要。
#### 2. 私密性与安全性
通过公网通信意味着你不仅要担心数据被窃听，还得处理繁琐的防火墙 IP 白名单。对等互连是完全私有的。公共互联网无法看到或访问这条链路，这为你的混合云架构提供了天然的安全隔离。
#### 3. 成本效益
相比于传统的 VPN 网关连接，对等互连通常成本更低。虽然跨区域对等互连会产生一定的数据传输费用（通常按出站流量计费），但省去了昂贵的 VPN 网关硬件费用和复杂的配置维护成本。
最佳实践与常见问题
在实际的生产环境中，我们不仅要让网络“通”，还要让它“稳”。下面是我在实践中总结的一些经验：
#### 常见错误 1：服务终结点与对等互连混淆
很多开发者会问：“我的 Web App 不能访问对等 VNet 里的 SQL 数据库，为什么？”
- 原因：你需要检查 虚拟网络服务终结点。仅仅建立对等互连是不够的，你还需要在 SQL 数据库所在的子网上启用“Microsoft.Sql”服务终结点，并在 SQL Server 的防火墙规则中允许该子网访问。这是一个经常被遗忘的步骤。
#### 最佳实践 1：使用 NSG 限制流量
不要因为是对等互连就认为它是绝对安全的。如果 INLINECODE1f0376fc 被攻破，黑客可以直接访问 INLINECODE17318da6。因此，务必在 INLINECODE96ffc259 的子网上应用严格的 网络安全组 (NSG) 规则。例如，只允许来自 INLINECODE0bd8beee 的特定 IP 段（如 10.1.0.0/16）的 3306 端口（MySQL）或 1433 端口（MSSQL）流量，拒绝其他所有流量。
#### 最佳实践 2：自定义路由与 UDR
虚拟网络对等互连会自动为每个 VNet 添加一条路由，告诉它们如何通过对方的 IP 地址空间到达对方。但是，如果你引入了 网络虚拟设备 (NVA)，比如 Palo Alto 防火墙，你需要配置 用户定义的路由 (UDR) 来强制流量流向防火墙进行检查，而不是直接通过对等链路传输。这种“透明代理”架构在企业级合规中非常常见。
总结与下一步
在这篇文章中，我们一起探索了 Azure 虚拟网络对等互连的奥秘。从解决最基本的跨网络通信问题，到理解非传递性这一核心概念，再到实际搭建连接并验证，我们已经掌握了构建云端复杂网络架构的基石。
这种技术彻底改变了我们在云端设计应用的方式，让“网关”不再是瓶颈，让数据中心之间的界限变得模糊。
既然你已经掌握了连接虚拟网络的能力，接下来可以尝试：
- 搭建中心辐射型网络：尝试在一个中心 VNet 中部署 Azure 防火墙，并让两个分支 VNet 通过对等互连，将流量转发到防火墙进行集中管控。
- 结合私有链接：将对等互连与 Azure Private Link 结合，进一步增强服务访问的安全性。
希望这篇文章能帮助你在云端架构设计的道路上更进一步。如果你在配置中遇到了 IP 冲突或路由表的问题，不妨停下来，用 route print 或类似的工具检查一下，答案往往就在底层网络逻辑之中。