Azure 国际站 Azure 微软云账号 VPN 网关搭建

前言：VPN 网关搭建，别把它当“玄学”

很多人第一次在 Azure 搭 VPN 网关时，第一反应通常是：怎么界面看起来像在考验耐心？第二反应是：为什么我填了所有参数，结果连接就是不上？第三反应更真实：是不是我电脑的 Wi-Fi 又在拖后腿？

放心，不是你电脑的问题（大概率）。Azure 的 VPN 网关搭建确实有些“配置感”，但只要你按流程把关键点（地址规划、网关类型、网关对端信息、路由方式、加密参数匹配）想明白，它就会像乐高一样，一块一块对上。本文就按“你真的要上线”的视角，把“Azure 微软云账号 VPN 网关搭建”讲清楚，并穿插一些常见踩坑与排查技巧。

你准备好了吗：搭建前清单（少走弯路）

在动手创建 VPN 网关之前，先把需求和环境梳理一遍。你少查一次资料，就少浪费一次人生的下午茶。

1. 明确你的场景：S2S 还是 P2S

Azure VPN 网关常见两类：

• 站点到站点（S2S）：企业本地网络（防火墙/路由器）与 Azure VNet 之间建立 VPN 隧道。你通常要接入“一个办公室或机房”。
• 点到站（P2S）：个人/用户设备通过 VPN 客户端直接连进 Azure。你通常要让“远程办公的用户”进入 VNet。

本文重点按“网关搭建”的通用思路来写，核心还是围绕 VPN 网关、连接和路由。你如果是 S2S，照着对端信息准备；如果是 P2S，也能按同样逻辑建立“从配置到验证”的闭环。

2. 网络规划：地址空间别乱来

VPN 最怕什么？怕地址打架。

至少你要确定三件事：

• Azure 侧 VNet 地址空间：例如 10.10.0.0/16 或 192.168.10.0/24。
• 本地侧网段：例如 172.16.1.0/24、172.16.2.0/24。
• 两边不要重叠：如果 Azure 和本地都用了 192.168.1.0/24，那你会得到一种特殊体验——“永远连不通但又说不清哪里错了”。

3. 你还需要准备：公网与设备能力

对 S2S 来说，你需要：

• 本地 VPN 设备的公网 IP（或至少对端能被 Azure 访问的地址）。
• 本地设备支持的 VPN 协议与参数（常见是 IKEv1/IKEv2、IPsec）。
• 预共享密钥（PSK）或证书方案（具体取决于配置）。

对 P2S 来说，你需要：

• Azure VPN 客户端的认证方式（证书/用户凭据等）。
• 客户端需要的地址分配策略（常见是 VPN 地址池）。

开始动手：创建 VNet 与子网（VPN 网关不只是“一个按钮”）

Azure VPN 网关需要依托一个 VNet。你不能在空中画一个隧道然后期待它自己长出来。

1. 创建或选择 VNet

你可以创建新的 VNet，也可以复用已有 VNet。建议：如果你已经有业务 VNet，那么把 VPN 网关部署在同一个 VNet 内（或用连接到 hub）。否则新建一个“hub”网络会更清晰。

在 Azure 门户里进入：虚拟网络（Virtual network）→ 创建。

重点：地址空间一定要配合你后续规划。

2. 创建 GatewaySubnet 子网

VPN 网关必须部署在特定子网里，常见名称为 GatewaySubnet。这个名字别随便改（Azure 对它很“讲究”）。

你需要：

• 子网名称：GatewaySubnet
• 子网大小：通常 /27 或更大（取决于网关 SKU 和配置）。

如果你子网太小，后续网关创建可能失败或性能不足。为了不让你反复创建，这里建议直接按官方建议的规模来。

3. 确认路由方式（动态还是静态）

Azure 国际站 VPN 网关的路由有两种常见路线：

• 基于策略的路由（policy-based）：依赖明确的路由策略。
• 基于路由的方式（route-based）：通过 BGP 或路由表实现更通用的转发。

Azure 中常见的做法是 route-based，尤其是企业场景。你不确定就先按默认/常用配置走，后面不通了再细查路由表。

创建 VPN 网关：从“你要的类型”开始选

现在到了激动人心的环节：创建 VPN 网关。

1. 选择网关类型与模式

进入：创建 → 网络 → VPN 网关（Virtual network gateway）。

你会看到选择项：

• 网关类型：VPN。
• VPN 类型：一般分为站点到站点（route-based / policy-based）或其他。
• SKU：不同性能和并发能力。

如果你搭的是 S2S，优先选择支持你场景的 route-based。SKU 则跟你的吞吐量有关，早期你可以先选一个合理的中等档位，不要一上来就“土豪模式”——钱会很诚实地告诉你心疼。

2. 配置公共 IP 地址

VPN 网关通常需要一个公共 IP。你可以新建公共 IP 或使用已有。

关键点：

• 公共 IP 通常是静态（Standard SKU 等）。
• 你要记录这个公共 IP，因为对端配置时可能会用到 Azure 侧公网地址。

3. 创建完成需要时间

别着急。VPN 网关创建往往会“慢慢来”，大概十几分钟甚至更久。你可以顺手检查：GatewaySubnet 是否存在、地址空间是否正确、是否有冲突。

创建本地网络网关（Local Network Gateway）

当你在 Azure 侧创建好了 VPN 网关，还缺一块拼图：Azure 需要知道“本地网络在哪里”。这就是 Local Network Gateway 的作用。

1. 本地公网 IP 与网段

在本地网络网关创建中，通常要填写：

• 本地网关的 IP 地址：本地 VPN 设备的公网 IP。
• 地址空间：你要通过 VPN 互通的本地网段列表。

常见错误：你以为“VPN 连接”就行了，结果本地设备的网段没填进去，Azure 侧永远不知道该把哪些流量发往隧道。

2. 多网段怎么处理

Azure 国际站 如果本地不止一个网段，就把多个地址空间加进去。Azure 支持你在 Local Network Gateway 中添加多个前缀。

但这里也有坑：如果你填了太多、不该路由的网段，就会导致路由混乱甚至安全策略混入不该走 VPN 的流量。保守一点，先把“必须的网段”放进去。

建立连接（Connection）：把隧道“拧紧”

创建 VPN 网关与本地网关后，最后一步是连接。

1. S2S 连接的关键参数

创建 VPN 连接时，通常会要求：

• 选择 Azure VPN 网关
• 选择本地网络网关
• 配置共享密钥（PSK）
• 配置 IKE / IPsec 策略（如加密算法、DH 组等）

你需要确保这些参数与本地 VPN 设备侧完全一致。不同步就会得到一个经典结果：隧道起不来，日志里会报认证失败或协商失败。

2. 连接建立的验证策略

连接创建成功≠真正通。你要验证：

• 连接状态是否显示为“已连接/Connected”。
• 两端隧道状态是否为 UP（本地设备查看 IPsec/IKE 状态）。
• 路由表是否指向 VPN 隧道。

建议你在本地设备侧先观察 IKE/IPsec 日志。如果 Azure 侧设置有问题，通常本地会先报出来。

路由与子网互通：为什么“隧道起来了也不通”

有一种情况非常常见：VPN 连接状态看似正常，但你 ping 不了、业务也不通。原因通常不是“VPN 坏了”，而是“路由没对”。

1. UDR（用户自定义路由）会抢走方向

如果你的 Azure 子网启用了 UDR 或强制路由，路由可能没有指到 VPN 网关。

排查方法：

• 检查 Azure 侧路由表（Route table）是否应用到目标子网。
• 查看有效路由中，目标本地网段的下一跳是否为 VPN 网关。

2. 本地侧也要有反向路由

VPN 隧道只负责“把数据搬过去”，但搬过去后得知道往哪返。

你要确保本地设备知道 Azure VNet 的地址空间，并将其路由到 VPN 隧道。

简单说：你能从 Azure 访问本地没意义，关键是双向互通。

3. 防火墙策略与安全组

就算路由对了，也可能被挡在门外：

• Azure NSG（网络安全组）拒绝了入站或出站。
• 本地防火墙拒绝了 VPN 源地址。

排查思路：先用最小范围测试，比如用同一个主机 IP 做连通性测试，并逐步扩大规则。

常见坑位排查：让你少掉 80% 的“为什么”

下面这些坑，是搭建 VPN 网关时最容易遇到的“老熟人”。你遇到任何一个，都别急，先对号入座。

坑 1：地址空间重叠

现象：VPN 隧道可能建立，但通信失败，甚至出现奇怪路由。

解决：重新规划网段，确保 Azure VNet 与本地网段不重叠。这个问题最“伤”，但也是最根本的。

坑 2：PSK 或加密参数不一致

现象：隧道建立失败，IKE协商失败。

解决：把本地 VPN 设备与 Azure 侧的 PSK、加密算法、DH 组等逐项对齐。很多时候你以为“都差不多”，但差的就是那一位参数。

坑 3：网关 SKU 不匹配需求

现象：连接能通，但吞吐不达标，或稳定性一般。

解决：根据业务吞吐与并发选择更合适的网关 SKU。早期你可以先用中等档位验证可用性，再升级。

坑 4：GatewaySubnet 配置不对

现象：创建网关失败或网关工作异常。

解决：确认子网名称是 GatewaySubnet，且子网地址范围符合要求（足够的大小）。

坑 5：本地设备公网 IP 不是“真正公网”

现象：Azure 侧一直连不上，日志提示对端不可达或协商失败。

解决：检查本地公网是否被 NAT、是否存在端口映射问题。尤其当你用防火墙或上层 NAT 时，要确认 Azure 能到达本地 VPN 设备。

坑 6：忘了开放必需端口

S2S VPN 常见需要 IKE 与 IPsec 相关端口（比如 UDP 500、UDP 4500，以及 ESP）。本地设备防火墙常常会“默认拒绝”，导致协商阶段就死掉。

解决：在本地设备上放行 Azure VPN 网关需要的端口/协议，且绑定到源地址（如果可以就精确）。

上线前的“像样检查”：别让客户在会议室里等

当你觉得“应该能用”时，建议做一轮小体检：

1. 连通性测试

• 从 Azure 内主机 ping 本地网段地址（或至少 ping 网关）。
• 从本地主机 ping Azure 内主机。

别只测试一个方向，更别只测一个 IP。网络这种东西，最擅长在你最放松的时候出问题。

2. 验证路由是否走隧道

在 Azure 侧可查看有效路由；在本地侧查看到 Azure 网段的路由是否指向 VPN 隧道。

Azure 国际站 如果路由都指错了，隧道再“UP”也只是把包搬到错误方向。

3. DNS 与应用层验证

VPN 通了 ≠ 应用通了。原因可能是 DNS 不通或解析错误。

建议：

• 确认 DNS 能解析远端域名（Azure 侧可用自定义 DNS，或本地 DNS 转发）。
• 用真实端口做应用测试（比如 RDP/SSH/HTTP/数据库端口），而不是只有 ping。

如果你是 P2S（点到站）：你会遇到哪些不同点

如果你的目标不是让两个网络互联，而是让远程用户直接进 VNet，那么 P2S 就登场了。

和 S2S 相比，你需要重点关注：

• 认证方式（证书或其他方式）。
• VPN 客户端地址池（给连入用户分配的地址范围）。
• 用户连接后能访问哪些网段（路由与 NSG 仍然重要）。

同样建议先做连通性与端口验证，不要因为“看起来配置完成”就放弃测试。

最佳实践：让你的 VPN 不只是“能用”，还要“好用”

搭建完成后，真正优秀的方案是可维护、可扩展、可排错。这里给你一些实用建议：

1. 先做 hub-and-spoke（如果你有多 VNet）

Azure 国际站 当你未来可能接更多业务 VNet，建议用 hub 网络集中部署 VPN 网关，通过 VNet Peering 进行扩展。

2. 统一命名与记录配置

你会在某个深夜需要回头看配置。那时你希望自己能在文档里一眼找到：

• Azure VPN 网关资源名、SKU
• Local Network Gateway 配置的网段与公网 IP
• 连接的 PSK、IKE 参数（可用安全方式存放）
• 路由表的规则

别靠记忆。记忆的寿命不如隧道的稳定性。

3. 保留排查证据

Azure 国际站 出现问题时，记录连接时间、日志关键错误、双方设备的协商失败信息，会让你排查时间从“几小时”压缩到“几分钟”。

结语：把隧道搭起来，把心态稳住

Azure VPN 网关搭建并不神秘。它只是把网络规划、加密协商、路由转发这三件事串起来：只要你每一步都认真做，把关键参数对齐，把地址规划先守住，再用连通性和路由验证收尾，基本就能顺利落地。

下一次你看到“隧道没起来”的提示，不要慌。先查本地设备能不能被访问，再对齐 PSK 与加密参数，然后核对网段是否重叠，最后看路由到底有没有指到对的下一跳。网络问题通常都有规律，规律不是用来吓人的，是用来省时间的。

如果你愿意，还可以把你的场景补充一下：你是 S2S 还是 P2S？本地设备型号是什么？你希望连通哪些网段？我可以根据你的信息，帮你把配置清单和排查步骤进一步“对症下药”。