Azure 现成账号批发 Azure微软云服务器内网互通设置

前言：内网互通这事儿，看似简单其实很“挑剔”

很多人第一次接触 Azure 虚拟机互通，会有一种感觉：不就是加个网段、开个端口、互相 ping 一下吗？然后你会发现——现实就像一道“看似有答案但答案藏在细节里”的题。Azure 的网络体系很强大，也很容易让新手在几个关键点上“差一口气”。

本文标题是“Azure微软云服务器内网互通设置”。我会用偏实操的方式，讲清楚：在同一个 VNet/同一个订阅/跨子网、甚至跨 VNet 的情况下，如何实现云服务器之间的内网互通；以及当你发现“明明都开了端口但就是不通”时，最常见的原因与排查顺序。

你不需要具备网络工程师背景，但需要愿意把“网络”当成一门需要验证的学科，而不是凭感觉操作的魔法。

你先搞清楚：Azure 里的“内网”到底指什么

在 Azure 里，大家口头说的“内网互通”，通常是指：

• 同一虚拟网络（VNet）内的不同子网之间，或同子网内不同 VM 之间，能通过私有 IP 通信。
• 通信路径主要走虚拟网络骨干，不走公网。
• 防火墙策略（NSG）和路由（UDR）等规则允许流量通过。

注意：Azure 的“内网”并不是你本地那种“随便建个网段就互通”。Azure 会用 VNet、子网、路由、NSG、必要时的网关等机制，控制流量如何流动。

方案总览：几台 VM 互通通常有三种情况

为了让你少走弯路，我建议你先判断你的需求属于下面哪一种：

情况一：同一 VNet、同一子网（最省心）

只要 VM 的网卡配置正确、NSG 放行了相关端口，一般就能互通。

情况二：同一 VNet、不同子网（常见）

大多数情况下，Azure 会通过默认路由让子网互通，但如果你启用了自定义路由（UDR）或修改了策略，就要格外注意。

Azure 现成账号批发 情况三：不同 VNet（需要额外连接能力）

如果要跨 VNet 通信，常见方法包括 VNet 对等互连（Peering）、VPN/ExpressRoute、或 Azure 里的其他网络拓扑。

准备工作：规划 VNet、子网与 IP 地址（别先开干再补洞）

在开始操作之前，建议你做一张简单的表格：每台 VM 所在的 VNet、子网、私有 IP、需要开放的端口、以及访问方向（谁连谁）。这能避免后面反复改配置。

一个合理的起手式是：

• 创建一个或多个 VNet（取决于你是否要跨 VNet 互通）。
• Azure 现成账号批发 在 VNet 内划分子网（例如 app-subnet、db-subnet）。
• 为 VM 规划固定私有 IP（可选，但强烈建议）。
• 列出互通需求：例如 Web（80/443）、SSH（22）、数据库（3306/5432）、内部服务端口（如 8080/9000）。

Azure 里“固定私有 IP”并不是必须，但在实际运维里非常省事。你会感谢自己：以后改了 DNS 或应用配置时，不用每次都重新猜 IP。

步骤一：创建/确认 VNet 与子网

如果你已经有 VNet，那就跳过。没有的话，按下面思路创建。

1）VNet 地址空间

选择一个不会和你现有网络（例如本地办公网、其他云网）冲突的网段。比如使用 10.10.0.0/16 这种较“干净”的地址空间。

2）子网划分

例如：

• app-subnet：10.10.1.0/24
• db-subnet：10.10.2.0/24

注意别把子网太挤了。你未来可能还会加 VM、加网关、加应用，子网不够就会很麻烦。

步骤二：把 VM 放进正确的子网（网络接口别弄丢）

每台 VM 都有网络接口（NIC），而 NIC 挂载到某个子网里。你的互通问题，很大概率发生在这里。

1）确认 NIC 所在子网

在 Azure 门户里打开 VM，找到“网络接口”，检查 NIC 是否在你预期的子网。

2）确认私有 IP

同一子网内不同 VM 应该有不同的私有 IP。并且你要确认 IP 是否与规划一致。

3）虚拟网卡的动态/静态设置

如果你要稳定访问（例如数据库、RPC），建议把关键 VM 设为静态私有 IP。

步骤三：NSG（网络安全组）才是真正的“门卫”

你会发现很多人开端口只是在“想象中开了”。Azure 实际是否放行，主要看 NSG 的规则。

1）NSG 可能挂在什么地方

NSG 可以挂在：

• 子网级别（影响该子网内所有资源）
• 网卡级别（更细粒度）

当你排查问题时，要注意优先级：如果子网级别和网卡级别同时存在规则，最终效果可能让你误会。

2）典型规则配置

假设你有两台 VM：web 在 app-subnet，db 在 db-subnet。

Azure 现成账号批发 你通常需要：

• 在 db 的 NSG：允许来自 app-subnet（或具体 web VM 私有 IP）的 3306（MySQL）或 5432（PostgreSQL）。
• 在 web 的 NSG：允许来自管理源的 22/80/443（按你的实际场景）。

另外要注意：Azure 的 NSG 默认是“拒绝”，你要用允许规则（Allow）把流量放进去。

3）不要只看“入站（Inbound）”，也要看“出站（Outbound）”

很多人只配了入站，结果还是不通，因为响应流量需要出站规则也允许。虽然在多数情况下 Outbound 可能是放开的，但你不能假设。

步骤四：路由与 UDR（当默认路由不工作时）

如果你只是“同 VNet 不同子网”，通常不需要你手动配路由。但如果你做过企业级改造，启用了自定义路由（UDR），那就要小心了。

你需要关注的点

• UDR 是否把目的地址的下一跳指向了“错误的地方”。
• 是否有强行把流量导入到虚拟网关或防火墙（NVA）导致路径变化。
• 路由表是否应用到相关子网。

排查方法通常是：在“有效路由/Effective Routes”里查看某个 VM 到目标 IP 的实际路由下一跳。这个“有效路由”就像体检报告：别只看你想怎么配，看看系统到底按什么走。

步骤五：DNS 解析（互通不等于互相“叫得出名字”）

互通的第一步是网络通；第二步是应用能找到对方。

如果你希望通过域名互相访问（比如 web 访问 db.internal 或服务名），建议做以下事情：

1）内部 DNS 习惯

Azure 中常见做法包括：

• 使用 Azure DNS 或自建 DNS（推荐更可控）。
• 在内网域名上做解析记录（A 记录指向私有 IP）。

2）不要指望所有机器自动知道对方

如果你的系统未配置 DNS 解析，可能会出现：ping 能通，但 curl 域名不通。或者服务启动成功但连不上数据库。

排查时建议先用 IP 验证网络，再用域名验证解析。

步骤六：测试与验证（别一上来就上生产级自闭式排障）

建议按“三段式测试”来做：

第一段：IP 连通性（ICMP 或端口探测）

从 VM A 到 VM B：

• 先测试是否能 ping（如果 ICMP 被禁用，换端口测试）。
• 再用端口探测工具验证目标端口是否可达，例如 22/80/443/3306 等。

第二段：路由有效性

在 Azure 控制台查看有效路由，确认下一跳是否合理。

第三段：应用层验证

例如：

• 数据库服务是否监听了正确的网卡/地址（0.0.0.0 或指定内网 IP）。
• 服务端防火墙（Linux iptables/UFW 或 Windows 防火墙）是否也允许对应端口。

你会惊讶于“NSG 放行但机器自己不让”的情况有多常见。Azure 防火墙和操作系统防火墙是两层不同的“围栏”。

跨子网互通的实战要点（同 VNet，不同子网）

当你把 web 和 db 分别放在 app-subnet 与 db-subnet 时，通常希望它们能直接通过私有 IP 互通。

这时候你应该重点检查：

• 两个子网的 NSG 规则：至少在 db 方向允许 web 的源。
• 是否启用了 UDR：有效路由是否仍指向系统默认路径。
• 目标服务是否监听了子网网卡地址。

一个很实用的排查顺序是：先确保 db 的 NSG 出站/入站允许，再确认 OS 防火墙，最后才去考虑路由。

跨 VNet 互通的实战要点（VNet 对等互连是常用解）

如果 web 在 VNet-A，db 在 VNet-B，你有两种常见选择：

方案 A：VNet Peering（对等互连，最常见）

你可以在两个 VNet 之间建立对等互连。建立后，通常可以实现私有 IP 的互通。

配置上要点包括：

• 两端都需要配置对等互连（通常是双向）。
• 检查“允许转发的流量/允许网关传递”等选项（按你的是否需要网关）。
• 检查每个 VNet 内各自的 NSG：仍然需要允许对应方向的流量。

方案 B：VPN/ExpressRoute（更偏企业级）

如果你需要接入本地机房或有更复杂拓扑，就可能用 VPN/ExpressRoute。但这类方案通常更复杂，本文以互通设置为主，不展开到“全家桶”。不过原则仍然一样：路由与防火墙决定一切。

常见踩坑清单（也是最省时间的部分）

下面这些坑你遇到任何一个，排查效率会直接从“正常”掉到“离谱”。提前看完能省不少怒气。

坑 1：NSG 看错作用域（子网 vs 网卡）

你以为你改的是网卡 NSG，结果目标 VM 实际挂的是子网 NSG 的规则生效。建议你确认 NSG 在哪个资源上应用，并留意是否有多层 NSG。

坑 2：允许规则写成了“来自任何人”，但目标出站/服务端没放行

看似宽松其实仍然不通。要检查：

• NSG 入站是否允许该源 IP/该端口
• NSG 出站是否允许响应方向
• 操作系统防火墙是否允许端口监听

Azure 现成账号批发 坑 3：数据库只监听了 127.0.0.1

应用层常见错误：数据库服务默认只监听本机回环地址，导致外部即使能到达也无法连接。

解决思路通常是让数据库监听内网网卡地址或允许远程连接（结合安全策略）。

坑 4：子网里没有足够 IP 或 IP 冲突（尤其你自己改过静态 IP）

IP 冲突可能导致奇怪的“时通时不通”。确认 VM 私有 IP 是唯一且属于正确子网。

坑 5：UDR 把流量导向了错误的下一跳

如果你启用了自定义路由，强烈建议你在“有效路由”里看目标 IP 的下一跳是什么。不要靠猜。

坑 6：DNS 解析失败导致“看上去网络不通”

你可能在排查时一直盯着 ping 或端口，但其实你访问的是域名，域名没解析出来。先用 IP 测网络，再用域名测解析。

一个典型案例：让 Web VM 能访问 DB VM

为了让你把概念落地，我给你一个“最常见”的场景。

假设：

• VNet：10.10.0.0/16
• app-subnet：10.10.1.0/24（web VM：10.10.1.4）
• db-subnet：10.10.2.0/24（db VM：10.10.2.8）
• 需求：web 访问 db 的 3306（MySQL）

你会这样做：

第一步：NSG 放行 db 的入站

在 db VM 所在的 NSG（子网或网卡，看你采用哪种管理方式）里加一条入站规则：

• 源：10.10.1.4 或 10.10.1.0/24（建议缩小范围）
• 目的端口：3306
• 允许（Allow）

第二步：确认 db 的出站/系统防火墙

一般出站是允许的，但你如果自定义过，就要检查对应方向。然后在 db VM 上确认 MySQL 监听地址不是只在 127.0.0.1。

第三步：在 web VM 上验证端口

从 web VM 去访问 db 的 10.10.2.8:3306，观察是否：

• 能连上：再测试登录与数据库权限
• 不能连：回到 NSG 和有效路由

到这里，你基本就能定位到是 NSG 问题、路由问题，还是应用监听问题。

排障策略：当你就是不通时，按这条“路线图”走

你可以把排障当成侦探工作。不要上来就“全都改一遍”。建议用下面顺序：

1. 确认目标是否在同一 VNet/子网：如果跨 VNet，先检查是否建立了 Peering 或其他连接。
2. 检查 NSG：入站 + 出站，源/目的 IP 范围、端口、协议（TCP/UDP）。
3. 检查操作系统防火墙：Linux 的 UFW/iptables，Windows 防火墙规则。
4. 检查服务是否监听：监听地址、端口是否在你想的那台上。
5. 检查有效路由：是否被 UDR 改写。
6. 检查 DNS：域名解析是否正确。

如果你按照这个顺序走，通常 80% 的问题会在前 3 步解决。剩下的才需要更深的网络诊断。

安全建议：互通要“能用”，但别“乱放”

实现互通只是第一目标，第二目标是把攻击面缩小。现实中最常见的事故是：为了先跑通，规则写得太宽，之后忘了收回来。

建议你：

• NSG 允许规则尽量限定源 IP 或源子网。
• 对管理端口（SSH/RDP）只开放给可信跳板机或管理网段。
• 服务端口也按需放行，不要“一把梭”。
• 保持变更可追踪：写清楚为什么开了某条规则。

总结：Azure 内网互通，本质是“路由 + 防火墙 + 应用监听”的协作

Azure 的网络系统并不神秘，只是逻辑比你想的更严格。内网互通的关键可以归纳为三句话：

• 网络路径是否存在：同 VNet/跨子网通常默认可达，跨 VNet 需要 Peering 或连接。
• 安全策略是否放行：NSG 是第一道门卫，操作系统防火墙是第二道门卫。
• 应用是否在等你：服务监听正确端口与地址，DNS 解析也别拖后腿。

当你遇到“不通”，请不要急着重装系统或狂改配置。按照“确认拓扑 → 看 NSG → 看 OS 防火墙 → 看服务监听 → 看有效路由 → 看 DNS”的路线走，你会越来越快，而且越来越稳。

Azure 现成账号批发 如果你愿意，可以在你实际的场景里告诉我：你是同 VNet 还是跨 VNet？web 和 db 分别在哪个子网？需要开放哪些端口？我可以帮你把 NSG/路由/测试步骤进一步“对号入座”，把那条不通的问题直接定位到最可能的原因。