Azure 12个月免费 Azure微软云服务器网络过滤设置

前言：云里也得“管得住”流量

在本地机房里，大家对“网络过滤”这事儿基本都熟：路由器/防火墙策略一条条贴上去，开几个端口，关几个端口，剩下的就交给规则去拦。可到了 Azure（微软云）之后，很多人会发现：同样是“过滤”，但工具长得不太一样，概念也容易互相打架。

你可能会遇到这样的经典场景：明明在服务器里开了端口，安全组里也看着没问题，但就是外面连不上；或者你放行了 80 端口，结果 HTTPS 不通；再或者你写了规则，却发现效力在另一层被“盖章”了。别慌，这篇文章就专门讲清楚 Azure 云服务器网络过滤设置该怎么做，怎么配才不容易踩坑。

先把概念捋顺：Azure 里到底“过滤”谁

Azure 的网络过滤常见涉及三类东西：网络安全组（Network Security Group，简称 NSG）、Azure 防火墙（Azure Firewall）、以及应用层/网络层的其他“配套控件”（比如路由、策略、第三方设备等）。你可以把它们理解成：门禁系统、保安亭、以及“你得先过安检再进楼”的那种额外流程。

NSG：最常用的“门禁规则”

NSG 是最常见的网络过滤方式，通常用于虚拟机（VM）子网或网卡（NIC）级别。你可以为入站（Inbound）和出站（Outbound）分别设置规则：

• 入站：外面谁能连进来（比如互联网访问 Web 服务器）。
• 出站：这台机器能访问外面哪些目的地（比如应用需要拉取更新包、连接数据库等）。

NSG 规则有优先级（默认按优先级数值从小到大生效），并且每条规则还会包含协议（TCP/UDP/ICMP 等）、端口、源/目的地址范围。

Azure Firewall：更像“专职保安亭 + 统一出入口”

当你想要更集中、更高级、更可审计的出站控制，或者希望对多个资源统一管理时，Azure Firewall 会更合适。它可以对出站进行更精细的策略管理，也适合和路由（UDR）配合使用，把流量引导到防火墙处。

不过本文重点会放在“云服务器网络过滤设置”的常用落点，也就是 NSG 的配置与排错，因为大多数团队从这里开始，最实用也最容易上手。

别忽略：关联位置决定生效范围

NSG 可以关联到两个地方：

• 子网级别：该子网内所有资源（通常是 NIC）都受影响。
• 网卡级别：只对某台机器的网卡生效。

如果你把 NSG 同时挂在子网和网卡上，那就要注意组合生效后的结果（规则可能叠加或被覆盖）。简单说：别同时在两个地方“写了两套宇宙规则”，最后自己都不清楚哪条才是对的。

入门配置：从“规则长什么样”开始

我们用一个常见需求开场：有一台 Azure 虚拟机作为 Web 服务器，希望外网访问 HTTP（80）和 HTTPS（443），同时允许服务器主动访问外部（比如下载依赖或访问外部 API），但不希望出现“随便谁都能扫端口”的情况。

第一步：明确你的流量方向与对象

• 外网访问 Web：属于 入站
• 服务器访问外部：属于 出站
• 需要限制的通常是：入站（谁能进来），以及出站（能不能随意出去）

第二步：建立 NSG（或使用默认的）

创建或选择 NSG 后，关键是要做“最小放行原则”：能精确到端口就别放整个协议栈；能限制到来源 IP 就别用 0.0.0.0/0。

例如：Web 服务入站规则通常这样想：

• 允许 TCP 80：源地址（建议限制为你的访问方或 CDN 网段；如果确实要开放互联网，再用 0.0.0.0/0）
• 允许 TCP 443：同上
• 拒绝其他入站端口：通过“默认拒绝”或显式规则实现

第三步：规则示例（以安全组方式）

假设你希望只开放 Web：

• 入站规则 1：Allow-HTTP，TCP，端口 80，源为你的地址范围，目标由系统隐含为资源本身
• 入站规则 2：Allow-HTTPS，TCP，端口 443，同上
• 入站规则 3：Deny-All-Other（可不显式写死，取决于 NSG 默认策略；但你至少要确保没有其他允许规则误放行）

出站规则方面：

• 一般来说，允许必要的出站（比如访问 DNS 53、HTTP/HTTPS 443 用于拉取依赖等）。
• 如果你要更严格，可以把出站目标限制到特定服务或地址段。

进阶：别只会放行，还要会“封得漂亮”

现实世界里，恶意扫描不会跟你讲道理。你要做的不是“开放得多”，而是“开放得刚好”。下面几个策略能显著提高网络过滤的质量。

策略一：限制来源地址（减少攻击面）

最简单有效的做法之一：不要让所有入站都来自 0.0.0.0/0，除非你真的必须公开服务。

例如：

• 运维管理（SSH/RDP）只允许你办公网络或跳板机所在的 IP 段访问。
• 数据库只允许来自应用服务器所在子网或应用服务器 IP 访问。
• 管理接口尽量限制到特定地址。

这一步的收益非常大：你防住的可能不是“黑客”，而是那种每天在互联网上四处扫端口的自动脚本。

策略二：使用端口与协议精确匹配

别把 TCP 80 放成“TCP 任意端口”，也别把 HTTPS 端口弄错。看起来是低级错误，但真的有人这么做，然后跑来问“为什么 443 还是不通”。

记住：NSG 是网络层过滤，应用层还得再看反向代理、应用监听端口、证书配置等。

策略三：优先级一定要想明白

NSG 中规则有优先级。优先级越小越先匹配。比如：

• Allow-HTTP（优先级 100）
• Deny-All-Inbound（优先级 200）

这样会产生正确效果：HTTP 先被允许，其他再被拒绝。反过来如果你把 deny 放在更前面，HTTP 也会被挡住。

建议你在团队内形成一个约定，比如：允许规则统一使用 100-199，拒绝/兜底规则使用 900-999，避免“你改我也改”的优先级冲突。

典型场景：按业务来配，不要凭感觉乱点

下面给你几个常见场景的网络过滤思路。你可以把它当成“配置地图”，用业务倒推规则。

场景 1：公网 Web 服务器（允许 80/443，禁掉其他入站）

需求：互联网用户可以访问网站；不要允许外部直接访问 SSH/RDP；让系统只开放必须端口。

NSG 入站规则：

• Allow TCP 80（源：Internet 或你的 CDN 网段）
• Allow TCP 443（源：Internet 或你的 CDN 网段）
• Deny 其他入站（确保没有额外 allow）

NSG 出站规则：

• Azure 12个月免费 允许解析 DNS（通常 UDP/TCP 53，具体看环境）
• Azure 12个月免费 允许访问外部的 80/443（拉取依赖、访问第三方服务）
• 其他可按需收紧

常见坑：

• 网站配置监听在 8080，但你放行的是 80/443。
• 容器/反向代理没起来，端口虽然放行了，但服务根本不在。
• 你配的是 NSG，但实际网卡关联的不是这个 NSG（或关联到错误子网）。

场景 2：数据库服务器（只允许应用访问，不允许公网直连）

数据库安全是重中之重。合理做法是：数据库不暴露公网，只让应用服务器能连。

假设应用服务器在某个子网（比如 app-subnet），数据库在 db-subnet。

NSG 入站规则（对数据库网卡或 db-subnet）：

• Allow TCP 3306（MySQL 示例），源为 app-subnet 或应用服务器 IP 段
• Allow TCP 5432（PostgreSQL 示例），源为 app-subnet 或应用服务器 IP 段
• Deny 其他入站

这样做的好处是：就算有人在互联网上猜到数据库端口，还是进不来。

额外建议：即使 NSG 限制了源地址，也建议数据库层再做最小权限账号与防爆破配置。

场景 3：运维跳板（RDP/SSH 不直接暴露）

很多团队喜欢“为了省事直接开 22/3389 给全网”。这种省事叫做“未来事故的预告片”。更稳的做法是跳板机（Bastion 或运维专用 VM），对外只开放跳板所需端口，对内再开放。

思路：

• 对业务机器：入站允许来自跳板机 IP 段的 SSH/RDP
• 对跳板机：入站只允许你的办公 IP 段（比如你家宽带或公司办公网出口）

这样你在外面要运维时，安全性主要由跳板机控制；业务机器不会直接沦为“互联网自由练习场”。

场景 4：封禁异常（只允许少量管理端口 + 记录与回溯）

当你遇到某类异常流量（比如某端口被频繁扫、某 IP 段异常），你可以做两件事：过滤和追踪。

过滤层面：

• 对管理端口（如 API 管理、内网接口）只允许特定来源。
• 必要时增加拒绝规则，优先级放到允许规则之前或之后取决于你想要的效果。

追踪层面：

• 确保网络日志或诊断日志开启（用于回溯是谁在打、打了什么端口、流量是否被拒绝）。
• 定期检查 NSG 规则是否被“临时放行”后忘记收回。

排错宝典：为什么“我都配了还是不通”

网络过滤配置最让人崩溃的时刻通常是：你觉得你做对了，但结果不对。下面给你一套实用的排错顺序（按优先级从高到低），基本能覆盖 80% 的问题。

第一步：确认你配到的是“正确的关联位置”

NSG 可能关联在子网或网卡。你要确认：

• 虚拟机的网卡是否关联了你以为的 NSG。
• 子网级 NSG 是否存在并影响了结果。

你可以把它理解成：你在门禁系统 A 放了“允许”，但这扇门实际用的是门禁系统 B。

第二步：方向别搞反（入站 vs 出站）

很多人只看“我想让外面进来”，然后只改了出站规则。注意：

• 外部访问 VM：看 入站
• VM 访问外部：看 出站

方向搞错就会出现一种很神奇的现象：你放行了，但其实不是同一条“路”。

第三步：端口与协议要对号入座

TCP 与 UDP 不同；80/443 不同；源端口也可能被误解（虽然 NSG 主要看目的端口）。你要确认：

• 规则里选择的是 TCP 还是 UDP
• 端口号是否一致
• 服务监听是否在该端口（在虚拟机里用命令或应用配置确认）

第四步：检查优先级与拒绝规则

Azure 12个月免费 如果存在“拒绝所有其他入站”的兜底规则，那么你新增的允许规则是否优先级更高（数值更小）就很关键。

建议做法：在规则名称上标注优先级范围，团队维护时不容易乱。

第五步：别忘了操作系统防火墙/应用监听

NSG 只是云网络层的过滤，不等于机器内部一定允许。

• Linux/Windows 防火墙是否放行端口？
• 应用是否确实在监听 0.0.0.0 或对应网卡地址？
• 是否被反向代理/容器网络配置影响？

一句话总结：网络过滤之外还有“地板上的地砖”，不对也会绊倒你。

第六步：用“验证工具/测试请求”缩小范围

排错时别凭感觉。你可以通过不同网络路径做测试：

• 从允许的源 IP 测试。
• 从不允许的源 IP 测试（确保确实被拒绝）。
• 在开放端口上做简单连接测试（例如访问 HTTP 返回状态）。

测试的目的不是炫技，是为了验证“规则是否按预期生效”。

最佳实践：让网络过滤可维护、可审计、少翻车

配置能跑起来是一回事，能长期维护又是另一回事。下面这些建议你可以拿去和团队“立规矩”。

实践 1：最小权限 + 先放行再收紧

Azure 12个月免费 初期搭建阶段可以稍微宽松，但要在上线前进行收敛。比如：

• 先确认服务可用
• 再把入站限制为必要端口与必要来源
• 最后检查出站是否过度开放

不要上线后才想起“哎我们之前为了调试放宽了一下”。这种“放宽”最容易在数周后成为安全债务。

实践 2：规则命名与分组有标准

建议命名包含：业务/环境/用途/协议端口。

例如：
dev-web-allow-https-tcp-443（开发环境 Web 允许 HTTPS）
prod-db-allow-mysql-tcp-3306-from-appsubnet（生产数据库允许来自应用子网的 MySQL）

当你两个月后回来看到这些规则，至少不会“看着像外星语言”。

实践 3：尽量使用子网 NSG 做统一管理

当你的虚拟机数量多且分层清晰（web/db/app 分子网），用子网级 NSG 管理会更直观。但如果你有“同一子网内少数机器例外”，再用网卡级 NSG 处理差异即可。

一句话：能用子网统一就别每台机器都手工加规则。

实践 4：开启日志与回溯

网络过滤一旦出了问题，日志就是救命稻草。确保你：

• 能看到拒绝/允许的记录
• Azure 12个月免费 能追溯源地址、目标端口、时间
• 能对异常进行统计

不然你只能靠“我觉得当时应该是这样”，那是推理小说，不是运维。

关于性能与规模：网络过滤也会影响体验

很多人关心“过滤会不会慢”。答案是：通常 NSG 的性能足够支撑绝大多数场景，但你需要注意两点：

• 规则数量：规则太多会让管理变复杂，也可能带来排错成本上升。
• 不必要的放宽：如果出站/入站规则特别宽泛，虽然不一定慢，但安全风险更大。

当规模很大或安全要求很高时，再考虑 Azure Firewall 或更系统的网络治理方案。

小结：把网络过滤当成“防守体系”，而不是“临时补丁”

Azure 微软云服务器的网络过滤设置，本质上就是：用 NSG/防火墙规则把流量分门别类，让你真正需要的进得来、不需要的进不来；同时让你允许出去的出去、拒绝出去的别出去。

如果你只记住三句话：

• 先想清方向（入站/出站），再下规则。
• 规则要精确（端口/协议/来源范围），别图省事开大。
• 排错按顺序（关联位置、优先级、端口协议、再到 OS/应用）。

这样你就不会再陷入“我明明配了为什么不通”的循环里。网络过滤不是玄学，是体系；是当你把规则当成防线，而不是临时贴纸时，它才真的可靠。

如果你愿意，我可以按你的实际环境给出规则草案

你可以告诉我：你的虚拟机用途（Web/数据库/应用/运维）、需要开放的端口、是否有跳板机、网络分层（web/app/db 是否有子网）、以及你希望允许的来源范围（例如某个办公室出口 IP 或公司 VNet）。我就能把“入站/出站 NSG 规则清单”帮你整理成可落地的配置方案，并标注常见坑位。