微软云海外版 微软云 Azure 账号虚拟网络构建

开场：虚拟网络不是“随便建建”，但也没那么吓人

很多人在第一次搭建 Azure 虚拟网络（Virtual Network，简称 VNet）时，会产生一种错觉：它就是个“网络容器”，把子网往里一塞就完事。对，也不对。对在于确实是个容器；不对在于——它决定了你的应用怎么通信、怎么出网、怎么隔离、怎么被访问。你以为在建网络，实际上你在替未来的自己“买单”。

本文以“微软云 Azure 账号虚拟网络构建”为主题，带你走一遍从规划到落地的思路。你可以把它当作一份能直接照着做的路线图：先把该想清楚的想清楚，再把该配置的配置齐全。顺便我也会把常见踩坑点用幽默口吻标出来，避免你在排错时像在黑暗里找袜子。

微软云海外版 第一步：先搞清楚 Azure 账号与网络的关系

在讲 VNet 之前，先聊“Azure 账号”这个词。很多人问的是“我在 Azure 门户里怎么建虚拟网络”。但在实际操作里，你会看到的主要结构包括：订阅（Subscription）、资源组（Resource Group）和资源本身（VNet、子网、NSG 等）。

1.1 订阅是什么？

订阅就像你的“付费与计费边界”。同一个 Azure 账号下可以有多个订阅。建网络时，你需要确认资源属于哪个订阅。订阅不同，配额、账单、权限可能都不一样。

1.2 资源组是什么？

资源组是你给一堆相关资源贴的“工作文件夹”。比如你要搭一个测试环境网络，那 VNet、子网、NSG、路由表等最好放在同一个资源组，方便管理、授权、删除和迁移。

1.3 VNet 在哪里“住”？

VNet 是一个区域性的资源（通常按区域部署）。你需要选定区域，比如 East Asia（东亚）或 Southeast Asia（东南亚）。同一个 VNet 不适合跨区域“乱放”；你可以用更合适的方式做跨区方案（这部分后面只点到为止，不展开）。

第二步：地址规划——别让网络“住进没有门牌的房子”

地址规划是虚拟网络构建最容易被忽略、但最影响后续扩展的部分。你现在随手选个地址段，以后要联通别的网络、加 VPN、接本地网段，就会发现自己像在给错过的列车补票。

2.1 选择合适的 IP 地址段

Azure VNet 的地址空间需要你提前决定。常见选择是使用私有网段，如 RFC1918：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。建议：

• 尽量选择一个不会和你现有网络（本地、其他云、实验室网络）冲突的网段。
• 为未来扩展预留地址空间，比如 /16 或 /20 视规模而定。
• 避免“今天就用一个子网”，明天就要搞一堆子网，地址不够只能硬改（硬改很痛）。

2.2 子网划分思路

子网（Subnet）是 VNet 内的网络分区。你可以按业务划分，例如：

• Web 子网：对外提供服务
• App 子网：业务处理
• DB 子网：数据库服务（强隔离）
• 管理子网：堡垒机/运维访问

也可以按访问方向划分，比如“面向互联网”“仅内网”“专用于出站”。具体怎么分看你的安全要求和部署架构。

微软云海外版 2.3 一个可落地的示例规划

假设你要做一个中小型环境，建议地址空间用一个较宽的范围，例如 VNet：10.10.0.0/16。

子网可以这样来：

• 微软云海外版 Web：10.10.1.0/24
• App：10.10.2.0/24
• DB：10.10.3.0/24
• Mgmt：10.10.4.0/24

如果你后续还要加一些服务，比如缓存、消息队列、跳板机，还能继续从 10.10.5.0/24 往下扩。

第三步：在 Azure 门户创建虚拟网络（VNet）

现在进入正题：如何在 Azure 账号里构建虚拟网络。

3.1 入口在哪里找？

一般你可以在 Azure 门户里通过搜索“虚拟网络”进入创建页面。选择订阅、资源组和区域，然后开始配置基础参数。

3.2 创建 VNet 的关键参数

• 名称：例如 vnet-prod-001。命名最好带环境和用途，未来你会感谢自己。
• 区域：选择离你的资源最近的区域。
• 地址空间：填你规划的网段，比如 10.10.0.0/16。
• 子网：一开始可以创建多个子网，也可以先建一个，后续再加。
• DNS 配置：可以采用系统默认或按需配置自定义 DNS（比如你有内部域名）。
• 路由与安全：通常会在后续设置 NSG、路由表。

3.3 子网配置要点

创建子网时，你需要：

• 为每个子网指定地址范围（比如 /24）
• 确认子网名称能看懂（web-subnet、db-subnet 这种即可）
• 如果你有计划启用特定服务（例如私有终结点 Private Endpoint），后续可能会影响子网策略或需要额外子网设计

别太纠结“第一次就全部规划完”，但也别胡乱建完就放着——至少把 Web/App/DB 的隔离思路做出来。

第四步：NSG（网络安全组）——把“谁能进来”写进规则里

虚拟网络里真正发挥“安全威力”的，通常离不开 NSG。NSG 是一套访问控制规则集合，能在子网或网卡级别生效。

4.1 NSG 作用机制：不是魔法，是规则

NSG 通过入站（Inbound）和出站（Outbound）规则控制流量。你可以按端口、协议、来源/目的 IP、服务标签来设置。

举例：Web 子网允许从 Internet 访问 80/443，App 子网只允许从 Web 子网访问特定端口，DB 子网只允许来自 App 子网访问 3306/1433 等。

4.2 建议的规则策略（示例）

• Web 子网 NSG：入站允许 80/443；其余尽量拒绝或限制；出站按需（例如允许访问外部更新包服务器）。
• App 子网 NSG：入站只允许来自 Web 子网的流量（比如应用端口 8080）；出站到 DB 子网放行。
• DB 子网 NSG：入站只允许来自 App 子网的数据库端口；禁止来自 Internet 的访问。
• Mgmt 子网 NSG：仅允许来自你固定跳板机/公司网络的访问；开启审计与限制强度。

别一上来就“全放行”，因为那不是网络，是自助餐。吃多了容易胃疼，排错时尤其。

4.3 常见 NSG 冲突点

• 子网级 NSG 与网卡级 NSG 同时存在：以有效规则为准，容易出现“明明以为放行了但还是不通”。
• 规则优先级：NSG 规则按优先级（priority）生效，低数字通常优先。你以为加了新规则，结果却被更高优先级的规则“压住了”。
• 忘了放行回程：入站放行了，但出站没考虑，或者方向写反，导致连接建立失败。

第五步：路由与出网策略——你想让流量走哪条路？

当你把 VNet 和 NSG 配好后，下一件事通常是“出网”。比如虚拟机需要访问外网更新、下载镜像、调用第三方 API。Azure 默认路由有一定能力，但遇到特定安全或混合网络场景，你会需要自定义路由（UDR，User Defined Route）。

5.1 默认路由是什么？

默认情况下，VNet 会有系统路由，把本地/对等/互联网等流量按规则引导。大多数新手在普通场景下不需要动路由表。

5.2 什么时候你需要自定义路由？

• 你要强制流量经过防火墙或网关（例如 Azure Firewall、第三方设备）。
• 你要实现特定的转发策略。
• 你在做复杂的混合网络（本地 + 云）并希望控制跨网段的转发路径。

这时你可以创建路由表（Route Table），在子网级别关联它，然后定义下一跳（Next hop）是互联网、虚拟网络网关、虚拟设备或其他。

5.3 一个典型的“出站走防火墙”场景

假设你启用了防火墙，你可能会希望：

• Web/App 子网所有 0.0.0.0/0 流量转发到防火墙私有 IP
• DB 子网尽量不直接出网（甚至完全禁止出站），让数据不“偷偷联系外面”

这样做的价值是：审计更清晰、策略更统一，但配置复杂度也会上升。你要的是“可控”，不是“省事”。

第六步：连通性验证——别等“用户说不通了”才发现

网络搭好了，不代表它真的通。建议在上线前做基础验证：从“同子网能不能通”到“跨子网能不能通”，再到“能不能访问外网、能不能解析域名”。

微软云海外版 6.1 同子网连通性

最简单的验证方式是：

• 部署两台虚拟机（或使用同一虚拟机测试工具）
• 测试彼此的端口访问（比如 ping、curl、telnet/ss 视系统）
• 确认安全规则与系统策略没有冲突

如果同子网都不通，通常是地址、网卡、NSG 或 Windows/Linux 防火墙没配好。别急，先把基础问题排掉。

6.2 跨子网连通性

跨子网的规则通常依赖 NSG。比如 Web 子网允许到 App 子网的端口，那么 App 子网的入站规则必须放行来自 Web 子网的来源。

常见错误：你在 Web 放行了端口，但忘记在 App NSG 放行入站；或者在 NSG 里写了来源 IP，却实际来源并不是那个 IP（例如你用了负载均衡或代理导致来源变成另一个地址段）。

6.3 出网连通性与 DNS

出网测试包括两个方向：

• 网络层：能否访问外网 IP（例如 1.1.1.1、8.8.8.8 或下载源）
• 应用层：域名是否能解析、HTTPS 是否能建立

DNS 问题特别常见：明明网络通了，但域名解析超时。你会看到服务端“卡在找地址”，这时候就需要检查 DNS 设置（系统默认 DNS 或自定义 DNS），以及是否有防火墙/代理影响 DNS 流量。

第七步：对等连接与混合网络（可选，但很常见）

很多企业最终不会只在一个 VNet 里玩，而是会使用多个 VNet，甚至与本地网络打通。Azure 提供了对等连接（VNet Peering）和混合连接（如 VPN Gateway、ExpressRoute 等）。

7.1 VNet Peering 的基本思想

微软云海外版 VNet 对等连接允许两个 VNet 之间进行内网级别通信（前提是路由与安全策略允许）。如果你做测试/生产分离，通常会在不同 VNet 中实现逻辑隔离，然后通过对等连接或网关来实现通信。

7.2 混合网络的关键难点

混合网络最大的难点往往是“路由与地址段冲突”。如果你本地网段是 10.10.0.0/16，而你在云里也用了 10.10.0.0/16，那么对接时就会变成“两个世界同名地址”。设备也会迷茫，后果就是不通。

所以，规划地址空间时，就要把“未来要对接本地”纳入考虑。

第八步：常见坑位清单（含吐槽版排错思路）

下面这些坑位，基本属于“每个新手都遇到、每个老手都曾经踩过”的传统项目。

8.1 子网地址段写错或重叠

子网不能重叠，也不能和其他网络冲突。你可能以为“我就随便写了个 10.10.1.0/24”，但当后续加了对等连接或 VPN，重叠问题会爆雷。

8.2 NSG 方向搞反

入站（Inbound）是外部流量打进来；出站（Outbound）是内部流量出去。你如果把规则写反，经常出现“看起来都放行了但就是不通”。

8.3 优先级导致规则被覆盖

你新加了“允许 443”的规则，可是旧规则里有“拒绝所有”的低数字优先级，于是新规则成了“写了但没被执行”。排错时要注意规则优先级，而不是只看是否存在。

8.4 没有考虑虚拟机操作系统防火墙

Azure NSG 放行了，但 Windows 防火墙没放行、Linux iptables/ufw 没开端口，你还是会以为“云没配对”。结论：不要只信云上的规则，也要看主机自己的门。

8.5 DNS 不通导致“看似网络问题”的假象

很多人以为是出网失败，实际是 DNS 解析失败。表现通常是：IP 地址能 ping 或能访问，但域名访问失败。解决方法是先判断解析，再判断网络。

第九步：一个从零到一的构建流程（你可以直接照做）

为了让你更像“开工做项目”，我把上面的内容压缩成一个实操流程。假设你要构建一个 Web/App/DB 的 VNet，并确保安全隔离。

9.1 流程概览

• 确定订阅、资源组、区域
• 规划 VNet 地址空间（例如 10.10.0.0/16）
• 创建 VNet，并创建子网：Web/App/DB/Mgmt（比如各 /24）
• 为子网创建/关联 NSG：放行必要端口，拒绝不必要流量
• 决定是否需要 UDR：如果要走防火墙就创建路由表并关联子网
• 部署测试资源（虚拟机或应用），进行跨子网、出网、DNS 验证
• 记录关键配置与规则，便于后续维护与审计

9.2 实际落地时的“时间顺序建议”

很多人喜欢先配一堆然后开始测试。我的建议是“够用先跑通，再逐步加安全与复杂度”。

• 第一轮：先搭通（放宽一点规则，验证基础连通性）
• 第二轮：逐步收紧（把最小权限的 NSG 规则补齐）
• 第三轮：加入出站策略（如果有防火墙/网关，再做 UDR 与验证）

这能减少一次性出错时的调查范围。网络问题就像“你家钥匙丢了”：你一次找全屋、全柜子，可能都在浪费时间；分阶段逐步排查会更有效。

第十步：运维与后续优化——让网络在未来也不崩

构建完成后，你还需要考虑一些运维与可观测性问题。否则网络虽然“能用”，但你遇到故障时可能像在看没有字幕的电影。

10.1 变更管理与文档

建议记录：

• VNet 与子网地址规划
• NSG 规则（关键端口、来源/目的、优先级）
• 路由表与下一跳配置（如果有）
• 与其他网络的连接方式（对等连接、VPN 等）

文档不需要写得像论文，但至少要在“半年后你还能看懂”的程度。

10.2 日志与监控

当网络策略变复杂时，日志会成为你的“真实证据”。比如 NSG 流日志、诊断日志等能帮助你定位：到底是被 NSG 拒绝了，还是路由不对，还是 DNS 出错。

如果你没有做日志，排错就只能靠猜。猜当然也能修，但成本会更高。

10.3 安全策略逐步强化

你可以逐步引入更严的策略，例如：

• 限制 Mgmt 子网的访问来源
• 数据库子网禁止出站
• 对外服务通过应用层网关或负载均衡集中管理

网络不是一次配好就永远不动。你要做的是让它“稳”和“可控”。

结尾：你已经完成了一次“像样的网络构建”

到这里，你的 Azure 账号虚拟网络构建已经从规划、创建、到安全与连通性验证走完了主线。最重要的收获不是某个按钮怎么点，而是你建立了一套可复用的思维：先规划地址，再分子网，再用 NSG 写清规则，最后用测试验证连通性，并在需要时引入路由与日志。

如果你愿意，把你目前的场景告诉我：比如你是要做测试环境还是生产、是否需要对接本地、规模大概多少台实例、是否要通过防火墙出网。你给我这些信息，我可以帮你把地址规划和 NSG 规则思路进一步“落到具体可执行版本”，让你少踩坑，少加班，多喝点快乐水。