Opsætning af GatewaySubnet i Azure: reserver pladsen før gatewayen

Åbn det virtuelle netværk i portalen, og se på adresområdet, før du rører subnetbladet. Hvis den /24 allerede er opdelt i arbejdsbelastningssubnet, og intet er frit, er der ikke plads til en /27-reservering, og du ender med enten at opdele igen eller udvide VNet, hvilket er en anden ændring med en anden gennemgang. Fastlæg pladsen først, og opret derefter subnettet.

Den rækkefølge betyder noget, fordi gateway-subnettet ikke er et arbejdsbelastningssubnet med et særligt navn. Det er adressereservationen til administrerede gateway-forekomster, og Azure afviser gatewayen, hvis reservationen er forkert.

Start med adresområdet

Skriv VNet-præfikset, arbejdsbelastningssubnettene og gateway-reservationen på én linje, før du taster noget. Et VNet på 10.60.0.0/16 har plads; vælg et interval i slutningen, så væksten i arbejdsbelastninger forbliver sammenhængende.

For eksempel efterlader 10.60.255.192/26 64 adresser til gatewayen, mens arbejdsbelastninger bliver i 10.60.0.0/20. Det er et eksempel på adresseplanlægning, ikke et løfte om størrelse. Microsoft kræver i øjeblikket /27 eller større til ikke-Basic VPN-gatewayer, hvor større betyder flere adresser: en /26 giver 64, mens en /28 giver 16. Rund op, aldrig ned, mens adresseplanen stadig flytter sig.

Opret subnettet med det præcise navn

Tilføj et subnet i portalen, og skriv navnet GatewaySubnet præcist, stort G og stort S, uden mellemrum eller suffiks. Azure matcher den streng, så Gateway-Subnet eller gateway giver et subnet, som gatewaytjenesten ikke bruger.

Det samme trin fra CLI’et, som er lettere at skrive ind i en gennemgang:

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

Lad subnettet være tomt. Ingen VM, ingen privat endpoint, ingen tjenestedelegering. Hvis der allerede bor noget der, mislykkes udrulningen, og fejlen nævner sjældent ressourcen, der er i vejen, så tjek subnettets resurseliste, før du begynder.

Hold det administrerede subnet fri af arbejdsbelastningsregler

Vedhæft ikke en netværkssikkerhedsgruppe til dette subnet; Microsoft markerer det som ikke understøttet. Knyt ikke en rutetabel, hvis standardrute sender 0.0.0.0/0 et eller andet sted hen, fordi det kan ødelægge gatewayens drift, og hold gateway-ruteudbredelse slået til.

Læg de adgangsbegrænsninger, du faktisk ønskede, på arbejdsbelastningssubnettet eller ved en inspektionsgrænse. At behandle GatewaySubnet som et almindeligt subnet er den fejl, der giver en gateway, som udruller pænt og derefter ikke fører trafik igennem.

Tvungen tunneling har sit eget dokumenterede design. En improviseret standardrute på gateway-subnettet er det ikke.

Tjek de afhængigheder, portalen ikke viser

Før du trykker opret, gå listen igennem: præcist navn, præfiks inde i VNet-pladsen, ingen overlapning med lokale intervaller, ingen arbejdsbelastningsressourcer indeni, ingen NSG og ingen rutetabel med en standardrute. Hver af dem har ødelagt en rigtig udrulning. Bekræft derefter det bredere design: den lokale netværksgateway til den lokale side, de adresområder, du forventer at route, og om aktiv-aktiv eller sameksistens er planlagt. De valg ændrer samtalen om størrelse, og de er meget billigere at afgøre nu.

Azure-referencen for gatewayindstillinger er den side, du citerer, når nogen spørger, hvorfor subnettet ikke kan rumme en VM.

Hvis gatewayen allerede findes

At ændre størrelse på eller udskifte et gateway-subnet er ikke en maskeredigering. Tjek først den understøttede ændringsprocedure for gatewayens SKU og generation, og list de afhængige objekter: forbindelser, offentlige IP’er, routing og eventuelle krav til gendannelse.

Hvis proceduren kræver, at gatewayen genskabes, skal du planlægge det som en tjenestemigrering med et vindue og en tilbagerulning. Notér den reservation, du valgte, begrundelsen for størrelsen og de regler, du bevidst ikke vedhæftede, så den næste gennemgang ikke reparerer det tomme subnet ved at tilføje en NSG.