Configuração do GatewaySubnet no Azure: reserve-o antes do gateway

Abra a rede virtual no portal e examine o espaço de endereços antes de tocar na folha da sub-rede. Se esse /24 já estiver dividido em sub-redes de carga de trabalho sem nada livre, não há espaço para uma reserva /27, e você acabará repartindo ou ampliando a VNet, que é outra mudança com outra revisão. Defina o espaço primeiro e só depois crie a sub-rede.

Essa ordem importa porque a sub-rede do gateway não é uma sub-rede de carga de trabalho com um nome especial. É a reserva de endereços para as instâncias gerenciadas do gateway, e o Azure recusará o gateway se a reserva estiver errada.

Comece pelo espaço de endereços

Escreva o prefixo da VNet, as sub-redes de carga de trabalho e a reserva do gateway em uma única linha antes de digitar qualquer coisa. Uma VNet em 10.60.0.0/16 tem espaço; escolha um intervalo no final para que o crescimento das cargas de trabalho continue contíguo.

Por exemplo, 10.60.255.192/26 deixa 64 endereços para o gateway enquanto as cargas de trabalho ficam em 10.60.0.0/20. Isso é um exemplo de planejamento de endereços, não uma promessa de dimensionamento. A Microsoft exige atualmente /27 ou maior para gateways VPN que não são Basic, onde maior significa mais endereços: um /26 dá 64, enquanto um /28 dá 16. Arredonde para cima, nunca para baixo, enquanto o plano de endereços ainda se move.

Crie a sub-rede com o nome exato

No portal, adicione uma sub-rede e digite o nome GatewaySubnet exatamente, G maiúsculo e S maiúsculo, sem espaços ou sufixo. O Azure compara essa string, então Gateway-Subnet ou gateway produz uma sub-rede que o serviço de gateway não usará.

O mesmo passo pela CLI, mais fácil de registrar em uma revisão:

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

Deixe a sub-rede vazia. Sem VM, sem ponto de extremidade privado, sem delegação de serviço. Se algo já mora ali, a implantação falha e o erro raramente nomeia o recurso que atrapalha, então verifique a lista de recursos da sub-rede antes de começar.

Mantenha a sub-rede gerenciada livre de regras de carga de trabalho

Não anexe um grupo de segurança de rede a esta sub-rede; a Microsoft marca isso como não suportado. Não associe uma tabela de rotas cuja rota padrão envie 0.0.0.0/0 para algum lugar, porque isso pode quebrar a operação do gateway, e mantenha a propagação de rotas do gateway habilitada.

Coloque as restrições de acesso que você realmente queria na sub-rede de carga de trabalho ou em um limite de inspeção. Tratar o GatewaySubnet como uma sub-rede comum é o erro que produz um gateway que é implantado sem problemas e depois não passa tráfego algum.

O túnel forçado tem seu próprio design documentado. Uma rota padrão improvisada na sub-rede do gateway não é isso.

Verifique as dependências que o portal não mostra

Antes de pressionar criar, percorra a lista: nome exato, prefixo dentro do espaço da VNet, sem sobreposição com intervalos locais, sem recursos de carga de trabalho dentro, sem NSG e sem tabela de rotas com rota padrão. Cada um desses já quebrou uma implantação real. Depois confirme o design mais amplo: o gateway de rede local para o lado local, os espaços de endereço que você espera rotear e se está previsto ativo-ativo ou coexistência. Essas escolhas mudam a conversa sobre dimensionamento, e é muito mais barato resolvê-las agora.

A referência de configurações do gateway do Azure é a página a citar quando alguém pergunta por que a sub-rede não pode hospedar uma VM.

Se o gateway já existe

Redimensionar ou substituir uma sub-rede de gateway não é edição de máscara. Verifique primeiro o procedimento de alteração suportado para a SKU e a geração do gateway, e liste os objetos dependentes: conexões, IPs públicos, roteamento e qualquer requisito de recuperação.

Se o procedimento exigir recriar o gateway, planeje como uma migração de serviço com janela e rollback. Registre a reserva escolhida, o motivo do tamanho e as regras que você deliberadamente não anexou, para que o próximo revisor não conserte a sub-rede vazia adicionando um NSG.