Azure 新加坡账号 Azure微软云内网互通设置

前言：把“云内互通”当成一条高速公路，而不是一场猜谜

你有没有遇到过这种场景：公司已经在 Azure 上跑起来了，应用都部署了，但当你想让 A 网段的服务访问 B 网段的资源时，网络像装了“隐身斗篷”——看得见但走不过。然后你开始怀疑人生：是不是安全组没放行？是不是路由没配？是不是 DNS 指向了错误的 IP？

说白了，“Azure 微软云内网互通设置”这件事，本质就是把不同网络之间的通信路径搭起来，并确保：1）能路由到；2）能解析到；3）能通过防火墙/安全策略；4）出了问题有人知道去哪里查。

本文按常见需求从易到难讲清楚：你到底该用 VNet Peering（VNet 对等连接）、VPN/ExpressRoute（专线/站点到站点）、还是 Private Link（私有访问）。顺便把 DNS 和路由的坑也提前铺好“防滑垫”。

先明确需求：你想互通的“范围”和“目的”是什么

很多网络事故不是配置不会，而是需求没先问清楚。建议你在动手前用三句话写清楚目标：

1）互通范围：同区域还是跨区域？同订阅还是跨订阅？

Azure 的互通方案跟“范围”强相关：

• 同区域、同或跨订阅：通常优先考虑 VNet Peering。
• 跨区域：VNet Peering 也能做，但你要配合好路由与设计（不同地区的 VNet 之间依然可以对等）。
• 企业级互通（本地到云、云到云、长期稳定）：更倾向 VPN/ExpressRoute。

2）互通目的：访问 IP/端口？访问域名？需要私密访问还是公开访问？

如果你只需要从一台虚拟机访问另一台虚拟机的某个端口（比如 3389、443），重点是路由与 NSG/防火墙放行。

如果你要访问某个域名（比如 app.company.com），DNS 也会成为关键角色。你以为你在配网络，其实你在和 DNS 玩捉迷藏。

如果你希望访问 Azure 服务时不走公共网络（比如存储、SQL、Key Vault），就要认真看看 Private Link。

3）约束条件：是否有合规要求？是否需要带宽、延迟、成本优化？

合规与安全往往要求“尽量走私网、不暴露公网”。带宽和延迟决定你选 VPN 还是 ExpressRoute。成本决定你到底要不要把每个环境都搞得像“城际铁路网”。

方案一：VNet Peering（最常用的“云内互通”）

VNet Peering 是 Azure 最常见的互通方式之一。它的直觉理解是：在两张 VNet 之间建立对等连接，让它们像同一个网络家族一样互相通信（前提是 IP 范围不冲突、策略允许）。

1）适用场景

• 需要让不同 VNet 内的资源相互访问。
• 通常不需要经过网关设备，想简化部署。
• 场景规模中等：用 Peering 很快能把通路搭起来。

2）关键前提：地址空间不要打架

Peering 不是“你能互通我就行”，它要求 VNet 地址空间之间不要重叠。否则路由会像共享同一个电话分机一样，让系统不知道该拨给谁。

Azure 新加坡账号 检查要点：

• VNet-A 的 CIDR 与 VNet-B 的 CIDR 不重叠。
• 规划好子网段：尽量用清晰命名，例如 10.10.1.0/24、10.10.2.0/24 这种看起来舒服的。

3）Peering 两端都要创建（并且要想清楚选项）

Azure 的 VNet Peering 是“双向”的。你通常要分别在 VNet-A 和 VNet-B 上创建“对等连接”。

创建时你会看到一些让人容易忽略的选项，建议逐个理解：

• 允许转发流量：如果你打算通过某些“中转/网关”转发流量，可能需要开启。普通场景通常可以先不开。
• 允许网关传递：涉及 VPN/ExpressRoute 网关时才会用到。
• 使用远程 VNet 的网关：同样是网关相关的组合需求。
• 允许 VNet 流量（或类似描述）：确保开启了对等通信相关能力。

如果你不确定要不要开，最稳妥的做法是先用“最小配置”跑通：先保证基本互通，再根据需求升级。

4）NSG/防火墙：别只配了 Peering 就以为万事大吉

Peering 解决的是“能不能到对方 VNet 的路由层”。但真正能不能访问，取决于：

• 源端到目的端的 NSG 入站/出站规则
• 目的端的 NSG 入站规则
• 如果有 Azure Firewall/NVA/防火墙策略，还会有更多过滤
• 应用层端口是否监听、协议是否一致

一个经典尴尬是：你明明能 ping 通，但访问 443 失败。原因通常是 NSG 没放行，或者服务只监听内网/IPv4，或者你用错了协议。

5）路由：UDR 和系统路由的配合

大多数情况下，Peering 会自动帮你完成路由到对方 VNet 的连通性。但如果你在子网上配置了 UDR（用户自定义路由），就可能改写了路由表。

排查思路：

• 在源端 VM 上看“有效路由”：是不是指向了错误的下一跳？
• 检查目的网段是否在 UDR 中被正确路由到对等链路，还是被“扭头带走”了。

注意：一些企业网络会把流量统一转到防火墙或网关，导致你在某个阶段“以为互通，实际被拦在中间”。这不是 Azure 的错，是你们的路由设计在跟你开玩笑。

6）DNS：域名解析别让它“指向公网的 IP”

如果你的应用使用域名访问对方服务，DNS 解析出来的 IP 会决定你走哪条路。

常见坑：

• 你以为域名解析到私网，但其实还是解析到公网。
• 你在不同 VNet 里用不同 DNS 服务器，导致返回不一致。
• 对某些 Azure 服务，如果没配置私有终结点相关 DNS，仍可能走公网。

解决方式通常包括：

• 配置私有 DNS 区域（Private DNS Zone）并链接到相关 VNet
• 必要时配置 DNS 转发或自建 DNS（例如 Windows DNS/Bind）
• 为 Private Link 或内部服务制定记录（A 记录/别名记录等）

方案二：跨订阅/跨区域的 Peering 设计建议

很多团队卡在“能配，但配完感觉不对”。跨订阅或跨区域时，你更需要注意设计一致性。

1）命名与资产归属要清晰

Azure 新加坡账号 建议你在命名中体现：

• 环境：dev/test/prod
• 区域：eastasia/westeurope 等
• 功能：app、data、shared-services

Azure 新加坡账号 不然你排障时会看到一串“vnet1、vnet2、vnet3”，然后你会开始写代码在脑内查表。

2）跨区域性能与故障域

跨区域互通一般是可行的，但要考虑：

• 延迟增加
• 某些依赖的服务会受区域影响
• 你需要提前制定容灾或降级策略

如果是生产核心业务，建议别临时把所有资源都扔到不同区域后才想起来“为什么这么慢”。

3）路由策略一致性

跨区域时，UDR 的策略更容易不一致。你要确保：

• 两个方向是否都按预期路由到对等链路
• 防火墙/网关（如果存在）处理跨区域流量是否符合预期

方案三：本地与 Azure 内网互通（VPN/ExpressRoute）

如果你的“内网互通”目标是让本地办公网或数据中心网段直接和 Azure VNet 通信，那通常要上 VPN 或 ExpressRoute。此时你不是在做“云内”，而是在做“云与云外的内网互通”。不过很多人标题写“云内互通”，实际需求是“云和本地互通”，所以这段别跳过。

1）站点到站点 VPN（S2S）

适用：

• Azure 新加坡账号 成本敏感、临时或中小规模互通
• 对带宽要求不极端

注意点：

• 网关配置要匹配（对端设备、隧道设置、密钥等）
• 本地与 Azure 的网段规划要避免重叠
• 路由传播（静态/动态）需要确认
• NSG/防火墙同样要放行

2）ExpressRoute（专线）

适用：

• 生产级稳定、低时延、合规要求高
• 需要更可控的带宽与可预测性

ExpressRoute 更偏企业网络架构范畴。你要做的不是“会不会配”，而是“配了之后运维能不能扛得住”。例如故障切换、监控告警、容量规划、变更流程等。

3）DNS：混合网络的“第二战场”

当本地到 Azure 建立互通后，域名解析也要统一策略。典型做法：

• Azure 新加坡账号 将私有 DNS zone 连接到 Azure VNet
• 本地 DNS 通过转发解析 Azure 内服务
• 必要时使用 Azure DNS Private Resolver 或自建 DNS 转发方案

别让应用在本地解析到错误 IP，然后流量走公网又被安全策略拦住。你会看到“网络不通”，但其实是“域名解析不对”。

方案四：Private Link（访问 Azure 服务的“私有通道”）

你可能发现：你在 VNet Peering 已经打通了，但访问 Azure 存储/数据库/Key Vault 仍然走公共地址或需要开防火墙白名单。此时 Private Link 就很香。

1）什么是 Private Link

可以理解为：让你访问某个 Azure 托管服务时，流量走私网地址，而不是公网终端。对安全性和合规性通常更友好。

2）适用场景

• 需要访问 Azure Storage/SQL/Key Vault 等服务，但不希望暴露公网
• 希望对访问来源进行控制，并降低数据外传风险

3）最常见的坑：Private DNS Zone 没配置好

Azure 新加坡账号 Private Link 的“通路”和“名字”必须一致。通常你需要：

• 创建或使用对应的 Private DNS Zone
• 把 Private DNS Zone link 到使用该服务的 VNet
• 确保应用使用的域名解析到私网 IP

如果你没做这些，即使网络通了，域名仍指向公网，连接可能被策略拒绝，或者绕行到你不想走的路径。

互通设置的“实操清单”：从零到通（按顺序做）

下面这部分你可以当作“步骤 checklist”。不保证你不踩坑，但能保证你踩坑时知道坑在哪里。

步骤 1：规划地址空间（最省时间的环节）

• 确认各 VNet 的 CIDR 不重叠
• 子网划分合理，不要用 10.0.0.0/8 这种看着大其实管起来更大麻烦的方案
• 明确哪些网段是生产、哪些是测试，别把它们混在同一个地址设计里

步骤 2：选择互通方案（别一上来就上复杂架构）

• VNet 之间互通优先 VNet Peering
• 需要本地互通上 VPN/ExpressRoute
• 访问 Azure 托管服务走私网用 Private Link

步骤 3：建立对等连接 / 隧道连接（并确认方向性）

• VNet Peering：确保两端都配置了对等
• VPN/ExpressRoute：确保对端设备和路由策略正确
• 如果有网关转发：确保相关选项开启

步骤 4：检查路由（有效路由比“感觉”更靠谱）

• 在源端 VM 查看有效路由，确认目标网段的下一跳正确
• 检查 UDR 是否影响了 Peering 的默认路由
• 如果有防火墙中转，确认策略对应

步骤 5：放行 NSG/防火墙规则（按最小权限思路）

• 只开放需要的端口和方向
• 临时排障可开放，但要设定回收计划（别变成“永远开放的通道”）
• 如果有多层安全（NSG + Azure Firewall + NVA），逐层验证

步骤 6：DNS 统一（让域名说人话）

• 域名是否解析到私网地址
• Private DNS Zone 是否已 link 到对应 VNet
• 跨 VNet 或跨网络时 DNS 转发策略是否一致

步骤 7：用“可观测”方式验证连通性

排障比“盲试配置”更重要。建议按顺序验证：

• Ping（仅判断基础连通性，不代表端口通）
• TCP 端口探测（例如用 curl/nc/PowerShell 测试）
• 应用日志（确认是否超时、是否被拒绝、是否走了错误 IP）
• 网络安全日志/防火墙日志（如果有）

排障宝典：当互通失败时，你该先怀疑什么

网络故障不是“全怪 Azure”，通常是按优先级能迅速定位。你可以按这个顺序查：

1）地址空间是否重叠？

这是硬伤。只要 CIDR 重叠，路由与通信就会变得不可预测。

2）Peering 是否建立且两端都正常？

有时你以为建好了，其实某一端的状态没生效，或者选项不符合预期。

3）是否被 NSG 拦住？

NSG 是最常见原因。尤其是：

• 入站没放行目标端口
• 出站没放行到对端网段
• 规则优先级顺序导致“你以为生效的规则没生效”

4）UDR 是否把流量“送去错误的下一跳”？

有效路由是你最可靠的朋友。

5）DNS 是否解析到错误 IP？

如果你访问的是域名，DNS 直接决定方向。你可能以为网络没通，其实是解析到公网或不存在的地址。

6）服务是否监听正确的网卡/协议？

比如服务只监听本机或只监听 IPv6，或者绑定在特定网卡上。网络通了也会“看起来不通”。

一些“人类写法”的设计建议：让你的互通长期可维护

很多互通不是一次性搞完就结束，而是后续不停扩容。你现在的设计决定了未来你会不会每次加一台 VM 都像开盲盒。

1）把环境隔离：dev/test/prod 最好用不同订阅或至少不同 VNet

你不想在周五晚上发现 prod 的数据库被 dev 的应用突然访问上了。隔离成本通常比事故成本低。

2）分层设计：应用层、数据层、共享服务层

例如：

• 应用 VNet：部署 Web/API
• 数据 VNet：放数据库、缓存
• 共享服务 VNet：放 DNS、跳板、监控代理等

这样互通关系更清晰，你也更容易写出“谁能访问谁”的安全策略。

3）DNS 作为基础设施对待，而不是“等有问题再补丁”

DNS 配得好，后面少掉一半痛苦。DNS 配得差，后面每次故障都得做“找 IP 猜测游戏”。

4）监控与日志别省：你要的是“能定位”，不是“能碰运气”

至少要做到：

• 网络安全日志可查
• 防火墙日志可追踪
• 关键服务日志可看超时/拒绝原因

常见问答：大家最爱问的几个点

Q1：VNet Peering 是不是“完全等同于一个 VNet”？

不是。它实现的是互通，但仍有策略选项、路由与 DNS 的差异。你可以把它理解为“强连通”，但不等同于同一个网络内没有边界。

Q2：Peering 和 Private Link 能同时用吗？

可以。Peering 负责 VNet 之间的私网连通；Private Link 负责访问 Azure 托管服务时走私网通道。两者目标不同，组合起来很常见。

Q3：为什么我明明开了 Peering，还不通？

最常见原因是：

• NSG/防火墙没放行
• UDR 把流量路由走偏了
• DNS 解析到了错误地址

Q4：跨订阅互通需要额外权限吗？

通常需要相应的网络资源权限来创建和管理对等连接或连接配置。具体取决于你们的权限模型（RBAC/策略）和订阅归属。

结语：把互通做成流程，而不是靠“老哥经验”

“Azure 微软云内网互通设置”听起来像是在研究高维物理，其实大多数问题都落在可执行的几块：地址空间、Peering/路由/NSG、安全策略、DNS 解析，以及最后的验证与排障。

如果你只记住一个原则，那就写在工单顶部：先保证路由能到，再保证端口能通，最后保证名字能对。 这样你就不会在“我到底是在配网络还是在配心情”的路上越走越远。

你要是愿意，可以把你当前的网络结构（VNet 数量、CIDR、是否跨订阅/跨区域、要访问的服务类型、是否用域名）简单说一下，我也可以按你的场景把方案收敛成一套更贴近你们环境的配置思路。