微软云代开户 Azure微软云网络安全组开放端口教程

开端口之前，先把“安全组”搞明白

在 Azure 上说到“开放端口”，大多数人的第一反应是：把端口一放，网络就通了。问题是——网络并不是你想象的“门口一开，里面随便进”。在 Azure 里，真正决定你能不能连上某台资源的，往往是三道门：路由、子网/网卡层的策略、以及最常被忽略但最爱“默默拦你”的——网络安全组（NSG）。

NSG 可以理解为一组“允许/拒绝规则”的集合。规则里写着：

• 进来的流量允许哪些？（入站）
• 出去的流量允许哪些？（出站）
• 从哪里来？（源地址/源端口）
• 到哪里去？（目标端口/目标）
• 优先级谁高？（规则优先级）

Azure 的默认策略有时会比较“高冷”：你以为已经开了端口，实际可能是规则还没生效、优先级被覆盖、或者你开错了位置（比如只在子网开了，但目标在网卡上又有更严格的规则）。所以这篇文章不光教你怎么“放行端口”，更会告诉你怎么避免把自己坑进网络黑洞。

你到底为什么需要开放端口？别急着开，先想清楚

微软云代开户 “开放端口”通常出现在下面几类场景：

• 你要访问虚拟机上的服务：SSH（22）、RDP（3389）、Web（80/443）、数据库等。
• 你部署了某个应用，需要从公网/指定 IP 调用某端口。
• 你要做运维：比如堡垒机或跳板机需要访问内网资源。
• 你要接入第三方：对方要求你的某端口可达。

但关键点来了：开放端口不等于“允许任何人访问”。你可以做到“只放行必要端口 + 限制源地址 + 选择合适的协议”。越早理解这一点，你越能把安全问题挡在门外。

先确认目标与位置：你要开的是哪一层？

NSG 可以关联到两种常见对象：

• 子网级别 NSG：作用于该子网下所有资源的网卡。
• 网卡级别 NSG：更精细，只影响该网卡。

很多人遇到“我加了入站规则，但还是连不上”，原因可能是：你以为自己在关联到目标资源所在的位置上改了规则，实际上 NSG 关联到别的子网/别的网卡，或者优先级导致你加的规则压根没生效。

所以在操作前，你最好先回答三个问题：

• 目标资源是什么？（VM 还是其他服务）
• 你要开放的端口是哪个？（比如 3389 或 443）
• 你该修改的是子网 NSG 还是网卡 NSG？

在 Azure 门户中开放端口：最常见的“可视化教程”

下面以“对某个虚拟机开放某个端口”为例讲清楚。不同资源的入口位置略有差异，但核心思路都一样：找到 NSG → 添加入站安全规则 → 设定协议、端口、源地址、优先级 → 保存 → 等待生效。

步骤 1：找到网络安全组 NSG

登录 Azure 门户后，进入：

• 搜索框输入“网络安全组”（Network security group）
• 打开对应 NSG

如果你还没有 NSG，可以先新建一个。一般建议：生产环境别把所有规则都堆在一个“全家桶 NSG”里，最好按业务拆分，后面排查会省你很多时间。

步骤 2：检查 NSG 与目标资源的关联

在 NSG 页面的左侧或顶部区域，找到“关联的资源”（或类似字样）。你要确认这个 NSG 已关联到：

• 该虚拟机所在子网，或
• 该虚拟机对应的网卡

如果你发现 NSG 还没关联上，添加规则就像在空旷草地上贴通行证——看着很热闹，但门口可能根本没人。

步骤 3：添加入站安全规则（核心）

在 NSG 页面里，找到“入站安全规则”（Inbound security rules），点击“添加”。常见字段建议这样理解并填写：

• 源：谁来访问。建议优先使用“指定 IP 地址”或“服务标记”。
  如果选“任何”，等于把门开到全世界，通常不建议（除非是 80/443 这种有安全措施的场景）。
• 源端口范围：一般对公网访问来说可用“*”（任意）。
• 目标：到本规则作用的资源/网卡即可。
• 目标端口范围：填你要开放的端口，例如 3389、22、80、443。
• 协议：对应端口的协议。比如 SSH/RDP 通常是 TCP，DNS 可能是 UDP。多数应用走 TCP。
• 操作（Action）：选择允许（Allow）。
• 优先级（Priority）：越小优先级越高。系统默认有一些规则，你添加的规则可能被覆盖。
• 名称：给规则一个能看懂的名字，例如 “Allow-HTTPS-From-OfficeIP”。

举例：你要从办公室公网 IP 访问虚拟机的 HTTPS（443）。你可以这样配：

• 源：你的办公公网 IP/网段（例如 203.0.113.10/32）
• 目标端口：443
• 协议：TCP
• 操作：允许
• 优先级：比如 100（避免和默认规则冲突）

步骤 4：保存并等待生效

点击“保存”。一般情况下规则会在短时间内生效，但建议你不要在保存后立刻做“天真”的网络测试。尤其如果你还有：

• 虚拟机 OS 防火墙（Windows Firewall/Linux iptables/ufw）
• 应用自身监听端口是否正确
• 路由/网关/私有链接是否影响入站流量

这些东西没准备好，你就会出现“NSG 明明放行了，但我就是连不上”的经典剧情。

别只会点按钮：PowerShell/CLI 开放端口也要会

如果你喜欢自动化，或者你在多环境重复部署（测试/预发/生产），那你肯定会想：能不能用脚本一键添加规则？当然可以。

下面给你 PowerShell 和 Azure CLI 的思路。注意：不同订阅/资源组/NSG 名称要替换。

PowerShell 示例：添加允许入站规则

思路：使用 Add-AzNetworkSecurityRuleConfig 或 New/Set 相关命令创建规则，然后把配置写回 NSG。

# 1) 先登录
# Connect-AzAccount

# 2) 变量配置（请替换）
$resourceGroupName = "YourResourceGroup"
$nsgName = "YourNSGName"

# 允许来自某个公网IP访问 443
$ruleName = "Allow-HTTPS-From-OfficeIP"
$priority = 100
$sourceAddressPrefix = "203.0.113.10/32"
$destinationPort = "443"

# 3) 获取 NSG
$nsg = Get-AzNetworkSecurityGroup -ResourceGroupName $resourceGroupName -Name $nsgName

# 4) 添加规则配置
$rule = "dummy"  # 占位，以下为说明用途。不同版本命令可能略有差异。

# 实际常见写法是构建规则配置并追加到 $nsg.SecurityRules
# 然后 Set-AzNetworkSecurityGroup 更新 NSG
# （由于不同环境 cmdlet 参数可能略不同，这里保留思路，不强行贴死某一版本命令）

# 你可以查阅对应 Az.Network 模块版本的文档来补齐具体 cmdlet 参数。

说句大实话：脚本这块受 Az 模块版本影响较大，所以我更建议你用“命令模板”方式——先在门户里创建一条规则，然后导出/对照参数，再把它迁移到脚本里。这样你能最快跑通并避免参数写错。

Azure CLI 示例：添加入站规则

Azure CLI 的思路也类似：使用 az network nsg rule create 创建规则并绑定到 NSG。

# 请替换变量
# 允许来自办公 IP 访问 3389
az network nsg rule create \
  --resource-group YourResourceGroup \
  --nsg-name YourNSGName \
  --name Allow-RDP-From-OfficeIP \
  --priority 110 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes 203.0.113.10/32 \
  --destination-port-ranges 3389 \
  --source-port-ranges '*' \
  --description "Allow RDP from office IP"

如果你成功执行，下一步就可以用网络测试或查看 NSG 规则列表确认规则状态。

优先级是灵魂：为什么你“开了端口却没用”

Azure NSG 规则有优先级（Priority）。规则引擎会按优先级从小到大匹配。一旦命中某条规则，就不会再继续找。

举个搞笑但真实的例子：你写了一条“允许来自你 IP 的 22 端口”，优先级设成 200。结果默认有一条“拒绝所有入站”的规则，优先级是 100，那么你的放行规则永远不会生效。你以为自己在开门，其实门口的保安（更高优先级规则）早就把你拦下了。

解决方式：

• 查看 NSG 里该端口相关的所有入站规则
• 确认优先级大小是否合理
• 必要时调整优先级或移除冲突规则

源地址怎么填才更安全：别学“全开侠”

NSG 的“源”选项是你安全策略的关键旋钮。常见填法：

• 指定 IP/网段：最安全且最可控。适合固定办公出口、跳板机公网地址等。
• 服务标记：适合让 Azure 官方服务访问你的资源。例如某些平台组件需要访问。
• 任何（Any）：最不建议。除非端口本身已经被应用层严格鉴权，并且你能接受攻击面暴露。

对运维端口（SSH/RDP）尤其不建议“任何”。如果你一定要开放，也尽量做：

• 限制到跳板机公网 IP
• 用 VPN/专线/零信任方案替代公网直连
• 开启更强的身份验证与审计

常见端口开放清单：你可能需要的那些

下面列一些常用端口及适用场景（提醒：只作为参考，实际仍取决于你的应用协议与监听配置）：

• 22/TCP：Linux SSH
• 3389/TCP：Windows RDP
• 微软云代开户 80/TCP：HTTP
• 443/TCP：HTTPS
• 3306/TCP：MySQL（通常建议别公网直露）
• 5432/TCP：PostgreSQL
• 6379/TCP：Redis（别轻易公网开放）
• 8080/TCP：某些 Web 应用临时端口

如果你要做数据库开放，建议优先走内网访问（VNet/VPN/私有终结点），把公网当作“最好别碰的地方”。数据库是攻击者最爱光顾的自助餐。

排错宝典：NSG 规则都配好了，还是连不上怎么办

当你遇到“开了端口但失败”，别急着怀疑宇宙。通常是以下几类原因：

1）你开了 NSG，但虚拟机操作系统防火墙没开

举例：

• Windows：Windows Defender Firewall 没允许入站端口
• Linux：iptables/ufw 没放行

解决：检查实例内防火墙，确保服务监听在正确端口，并允许对应入站。

2）应用没监听在你开放的端口

比如你以为服务跑在 443，实际上它只监听在 8443 或本机某个地址上。NSG 放行的是“门口允许”，但你房间里没开门缝还是白搭。

解决：在虚拟机上检查端口监听（例如 netstat/ss/lsof），确认服务确实在目标端口等待连接。

3）规则关联错了对象

你在子网 NSG 里添加规则，但实例其实在另一个子网；或者实例网卡还有另一个 NSG，更严格的规则覆盖了你的放行。

解决：确认 NSG 绑定位置，必要时同时检查子网级与网卡级的规则。

4）优先级冲突

你开了允许，但存在更高优先级的拒绝。

解决：检查同方向（入站）、同协议、同端口相关规则的优先级。

5）你以为是 TCP，实际服务用的是 UDP

例如某些协议可能走 UDP。你写了 TCP，就等于对着错误的车道挥手。

微软云代开户 解决：确认服务协议。

6）你用的是错误的源地址

很多人使用家庭网络/公司网络，公网出口可能变动，源 IP 不是你以为的那个固定地址。

解决：在测试机上确认实际源公网 IP，并把它填进 NSG 源地址。

7）你在内网场景忘了考虑路由/网关

如果你走的是 VPN/ExpressRoute/私有网络架构，可能还存在额外的安全设备或路由策略。

解决：结合网络拓扑排查，必要时抓包/做连通性测试。

如何验证“真的放通了”：别只看规则看心情

放通验证建议从“外到内”：

• 外部连通性测试：从你的客户端（或测试机）对目标公网 IP+端口发起连接测试。
• 实例内部检查：确认服务监听且防火墙规则与 NSG 对齐。
• 日志与审计：如果有诊断日志，查看是否有入站被拒/被允许的迹象。

测试方式可以是浏览器访问、curl（HTTP/HTTPS）、或使用网络工具测试 TCP 端口。看到连接成功才算数，看到“NSG 已添加规则”只能说明你在操作台上赢了键盘，并不代表网络真的通了。

更安全的替代方案：如何少开端口就把事办成

你可能会发现：很多时候我们开端口是为了“访问服务”。那有没有更稳、更安全的方式？有：

• 限制源 IP：把“Any”变成具体网段。
• 用跳板机：公网只暴露 22/3389 给跳板机，其它资源走内网。
• 微软云代开户 使用 VPN/零信任：避免公网直连管理端口。
• 只开应用需要的端口：别为了“图省事”把一堆端口全放行。
• 把管理面收口：比如管理 API、数据库只在内网开放。

安全这件事很像养猫：你可以让它进屋，但别把窗户每次都敞开。敞开一次也许没事，但习惯一旦形成，之后就很难收场。

完整小案例：只开放 443 给办公室，实现 Web 服务可访问

假设你有一台虚拟机部署了 Web 服务，使用 HTTPS（443），你希望只允许办公室公网 IP 访问。

你可以这样做：

• NSG 添加入站规则：协议 TCP，目标端口 443，源地址设置为办公室公网 IP/32。
• 优先级设置为合适的数字，避免与默认拒绝规则冲突。
• 确认 NSG 已关联到该 VM 所在网卡或子网。
• 在 VM 内检查 Web 服务监听 443，OS 防火墙允许入站。
• 从办公室网络测试访问：浏览器打开 https://目标域名或 IP。

微软云代开户 如果访问失败，按排错宝典检查：规则关联、优先级、OS 防火墙、监听端口、源 IP 是否变化。

开放端口的小抄：你可以照着写规则

为了让你真正“写得出来”，这里给一张文字小抄（你可以直接改数字就用）：

• 开放 SSH：入站允许，TCP，目标端口 22，源地址=跳板机 IP/公司出口 IP，优先级=100-200，动作=Allow。
• 开放 RDP：入站允许，TCP，目标端口 3389，源地址=管理员办公 IP，优先级=110-210。
• 微软云代开户 开放 HTTPS：入站允许，TCP，目标端口 443，源地址=Any（不建议）或公司网段（建议），优先级=100-300。
• 开放 HTTP：入站允许，TCP，目标端口 80，源地址=同上（常用于重定向到 443）。

记住：端口要开，但别把“源”开成“世界”。世界很大，流量很杂，安全策略要更精确。

最后总结：开端口的正确姿势

Azure 开放端口本质上是在 NSG 中添加“入站允许规则”，并确保：

• 规则方向正确（入站 vs 出站）
• 协议正确（TCP/UDP）
• 目标端口正确
• 源地址正确（尽量不要用 Any）
• 优先级没有被更高优先级规则覆盖
• NSG 关联到正确的子网/网卡
• 虚拟机 OS 防火墙与应用监听也同时正确

你照做一遍，基本就能把“端口不通”的谜团解开。至于剩下的那一点点玄学，通常不是玄学，是你漏检查了某个环节：比如优先级冲突，或者 OS 防火墙没放行。

好了，接下来就去 Azure 门户里动手吧。把端口开得明明白白，也把安全做得干干净净。愿你的网络永远“通”，而不是“通了但你以为没通”。