Azure GatewaySubnet 配置：先预留网段，再建网关

在门户中打开虚拟网络，先看地址空间，再动子网边栏。如果那个 /24 已经被工作负载子网切分，没有剩余空间，就没有地方放 /27 的预留；最后你要么重新切分，要么扩宽 VNet，而后者是另一项需要另行评审的变更。先定好空间，再创建子网。

这个顺序很重要，因为网关子网不是带特殊名字的工作负载子网。它是为受管网关实例预留的地址，预留错了 Azure 会拒绝创建网关。

从地址空间开始

在输入任何内容之前，把 VNet 前缀、工作负载子网和网关预留写在同一行。10.60.0.0/16 的 VNet 还有余量；把范围选在末尾，好让工作负载的增长保持连续。

例如，10.60.255.192/26 给网关留下 64 个地址，同时工作负载仍留在 10.60.0.0/20。这是地址规划示例，不是容量承诺。Microsoft 目前要求非 Basic VPN 网关使用 /27 或更大的范围，这里的更大意味着地址更多：/26 给出 64 个，而 /28 只有 16 个。地址方案还在变动时，一律向上取整，绝不向下。

用确切的名称创建子网

在门户中添加子网，把名称一字不差地输入为 GatewaySubnet：大写 G、大写 S，不加空格或后缀。Azure 按字符串匹配，所以 Gateway-Subnet 或 gateway 建出来的子网，网关服务不会使用。

同样的步骤用 CLI 写，便于放进评审记录：

az network vnet subnet create --resource-group rg-hub --vnet-name vnet-hub --name GatewaySubnet --address-prefixes 10.60.255.192/26

让子网保持为空。不放 VM、不放专用终结点、不做服务委派。如果那里已经有东西，部署会失败，而报错很少指出挡路的资源，所以动手前先看子网的资源列表。

让受管子网不沾工作负载规则

不要给这个子网关联网络安全组；Microsoft 明确标注为不支持。也不要关联默认路由把 0.0.0.0/0 发往别处的路由表，因为那会破坏网关运行；同时保持网关路由传播开启。

把你真正想要的访问限制放在工作负载子网上，或者放在检查边界上。把 GatewaySubnet 当普通子网对待，正是那种让网关顺利部署、却什么流量都过不去的错误。

强制隧道有自己的文档化设计。在网关子网上临时加一条默认路由，并不是它。

检查门户没有显示的依赖项

按下创建之前，逐条过一遍清单：确切名称、前缀在 VNet 空间内、不与本地网段重叠、内部没有工作负载资源、没有 NSG、没有带默认路由的路由表。这些都曾弄坏过真实部署。然后再确认更大的设计：本地侧的本地网络网关、你打算路由的地址空间，以及是否计划双活或共存。这些选择会改变容量讨论，而现在定下来要便宜得多。

当有人问子网为什么放不下 VM 时，该引用的页面是 Azure 网关设置参考。

如果网关已经存在

调整或替换网关子网不是改掩码。先查网关 SKU 和代次支持的变更流程，并列清依赖对象：连接、公共 IP、路由以及任何恢复要求。

如果流程要求重建网关，就按带维护窗口和回滚的服务迁移来规划。记录你选的预留、这么定大小的理由，以及你有意没有附加的规则，免得下一位评审者靠加一条 NSG 来修好这个空子网。