Oppsett av GatewaySubnet i Azure: reserver plassen før gatewayen

Åpne det virtuelle nettverket i portalen og se på adresserommet før du rører subnetbladet. Hvis den /24 allerede er delt i arbeidsbelastningssubnett og ingenting er ledig, er det ikke plass til en /27-reservering, og du ender med å enten dele på nytt eller utvide VNet, som er en annen endring med en annen gjennomgang. Fastsett plassen først, og opprett deretter subnettet.

Den rekkefølgen betyr noe fordi gateway-subnettet ikke er et arbeidsbelastningssubnett med et spesielt navn. Det er adressereserveringen for administrerte gateway-forekomster, og Azure vil avvise gatewayen hvis reserveringen er feil.

Start med adresserommet

Skriv VNet-prefikset, arbeidsbelastningssubnettene og gateway-reserveringen på én linje før du taster noe. Et VNet på 10.60.0.0/16 har plass; velg et intervall på slutten slik at veksten i arbeidsbelastninger holder seg sammenhengende.

For eksempel lar 10.60.255.192/26 64 adresser være igjen til gatewayen mens arbeidsbelastninger blir i 10.60.0.0/20. Det er et eksempel på adresseplanlegging, ikke et løfte om størrelse. Microsoft krever for tiden /27 eller større for VPN-gatewayer som ikke er Basic, der større betyr flere adresser: en /26 gir 64, mens en /28 gir 16. Rund opp, aldri ned, mens adresseplanen fortsatt beveger seg.

Opprett subnettet med det nøyaktige navnet

I portalen legger du til et subnett og skriver navnet GatewaySubnet nøyaktig, stor G og stor S, uten mellomrom eller suffiks. Azure sammenligner den strengen, så Gateway-Subnet eller gateway gir et subnett som gatewaytjenesten ikke bruker.

Det samme trinnet fra CLI, som er lettere å skrive inn i en gjennomgang:

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

La subnettet være tomt. Ingen VM, ingen privat endepunkt, ingen tjenestedelegering. Hvis noe allerede bor der, mislykkes distribusjonen, og feilen nevner sjelden ressursen som står i veien, så sjekk ressurslisten til subnettet før du begynner.

Hold det administrerte subnettet fritt for arbeidsbelastningsregler

Ikke knytt en nettverkssikkerhetsgruppe til dette subnettet; Microsoft merker det som ikke støttet. Ikke knytt en rutetabell der standardruten sender 0.0.0.0/0 et eller annet sted, fordi det kan ødelegge gatewaydriften, og hold gateway-ruteutbredelsen på.

Legg tilgangsbegrensningene du faktisk ønsket på arbeidsbelastningssubnettet eller ved en inspeksjonsgrense. Å behandle GatewaySubnet som et vanlig subnett er feilen som gir en gateway som distribueres rent og deretter ikke slipper gjennom trafikk.

Tvunget tunnellering har sitt eget dokumenterte design. En improvisert standardrute på gateway-subnettet er det ikke.

Sjekk avhengighetene portalen ikke viser

Før du trykker opprett, gå gjennom listen: nøyaktig navn, prefiks inne i VNet-rommet, ingen overlapping med lokale områder, ingen arbeidsbelastningsressurser inni, ingen NSG og ingen rutetabell med en standardrute. Hver av disse har ødelagt en ekte distribusjon. Bekreft deretter det bredere designet: den lokale nettverksgatewayen for den lokale siden, adresserommene du forventer å rute, og om aktiv-aktiv eller sameksistens er planlagt. De valgene endrer samtalen om størrelse, og de er mye billigere å avgjøre nå.

Azure-referansen for gatewayinnstillinger er siden du siterer når noen spør hvorfor subnettet ikke kan romme en VM.

Hvis gatewayen allerede finnes

Å endre størrelse på eller erstatte et gateway-subnett er ikke en maskeredigering. Sjekk først den støttede endringsprosedyren for gatewayens SKU og generasjon, og list de avhengige objektene: tilkoblinger, offentlige IP-er, ruting og eventuelle krav til gjenoppretting.

Hvis prosedyren krever at gatewayen gjenskapes, planlegg det som en tjenestemigrering med et vindu og en tilbakerulling. Noter reserveringen du valgte, begrunnelsen for størrelsen og reglene du bevisst ikke knyttet til, slik at neste gjennomgang ikke reparerer det tomme subnettet ved å legge til en NSG.