Konfigurera GatewaySubnet i Azure: reservera det före gatewayen

Öppna det virtuella nätverket i portalen och titta på adressutrymmet innan du rör subnetbladet. Om det /24:t redan är uppdelat i arbetsbelastningssubnät utan något ledigt finns det ingen plats för en /27-reservering, och du slutar med att antingen dela om eller bredda VNet, vilket är en annan ändring med en annan granskning. Fastställ utrymmet först och skapa sedan subnätet.

Den ordningen spelar roll eftersom gateway-subnätet inte är ett arbetsbelastningssubnät med ett särskilt namn. Det är adressreserveringen för hanterade gateway-instanser, och Azure avvisar gatewayen om reserveringen är fel.

Börja med adressutrymmet

Skriv VNet-prefixet, arbetsbelastningssubnäten och gateway-reserveringen på en rad innan du skriver något. Ett VNet på 10.60.0.0/16 har plats; välj ett intervall i slutet så att arbetsbelastningarnas tillväxt förblir sammanhängande.

Till exempel lämnar 10.60.255.192/26 64 adresser till gatewayen medan arbetsbelastningarna stannar i 10.60.0.0/20. Det är ett exempel på adressplanering, inte ett löfte om storlek. Microsoft kräver för närvarande /27 eller större för VPN-gatewayer som inte är Basic, där större betyder fler adresser: en /26 ger 64, medan en /28 ger 16. Avrunda uppåt, aldrig nedåt, medan adressplanen fortfarande rör sig.

Skapa subnätet med det exakta namnet

Lägg till ett subnät i portalen och skriv namnet GatewaySubnet exakt, stort G och stort S, utan mellanslag eller suffix. Azure jämför strängen, så Gateway-Subnet eller gateway ger ett subnät som gatewaytjänsten inte använder.

Samma steg från CLI, som är lättare att skriva in i en granskning:

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

Lämna subnätet tomt. Ingen VM, ingen privat endpoint, ingen tjänstedelegation. Om något redan bor där misslyckas distributionen och felet namnger sällan resursen som står i vägen, så kontrollera subnätets resurslista innan du börjar.

Håll det hanterade subnätet fritt från arbetsbelastningsregler

Koppla ingen nätverkssäkerhetsgrupp till detta subnät; Microsoft markerar det som ej stödd. Koppla ingen routtabell vars standardrutt skickar 0.0.0.0/0 någonstans, eftersom det kan bryta gatewaydriften, och håll gateway-rutspridningen påslagen.

Lägg de åtkomstbegränsningar du faktiskt ville ha på arbetsbelastningssubnätet eller vid en inspektionsgräns. Att behandla GatewaySubnet som ett vanligt subnät är felet som ger en gateway som distribueras rent och sedan inte släpper igenom någon trafik.

Tvingad tunnling har sin egen dokumenterade design. En improviserad standardrutt på gateway-subnätet är det inte.

Kontrollera beroendena som portalen inte visar

Innan du trycker på skapa, gå igenom listan: exakt namn, prefix inom VNet-utrymmet, ingen överlappning med lokala intervall, inga arbetsbelastningsresurser inuti, ingen NSG och ingen routtabell med en standardrutt. Var och en av dessa har brutit en verklig distribution. Bekräfta sedan den bredare designen: den lokala nätverksgatewayen för den lokala sidan, adressutrymmena du förväntar dig att routa och om aktiv-aktiv eller samexistens planeras. De valen förändrar samtalet om storlek, och de är mycket billigare att avgöra nu.

Azure-referensen för gatewayinställningar är sidan att citera när någon frågar varför subnätet inte kan hysa en VM.

Om gatewayen redan finns

Att ändra storlek på eller byta ut ett gateway-subnät är inte en maskredigering. Kontrollera först den stödda ändringsproceduren för gatewayens SKU och generation, och lista de beroende objekten: anslutningar, offentliga IP-adresser, routning och eventuella återställningskrav.

Om proceduren kräver att gatewayen återskapas, planera det som en tjänstemigrering med ett fönster och en återställning. Anteckna reserveringen du valde, skälet till storleken och reglerna du medvetet inte kopplade, så att nästa granskare inte reparerar det tomma subnätet genom att lägga till en NSG.