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

Opne det virtuelle nettet i portalen og sjå på adresserommet før du rører subnetbladet. Viss den /24 allereie er delt i arbeidslastsubnett og ingenting er ledig, er det ikkje plass til ein /27-reservasjon, og du endar med å anten dele på nytt eller utvide VNet, som er ei anna endring med ein annan gjennomgang. Fastset plassen først, og opprett deretter subnettet.

Den rekkjefølgja betyr noko fordi gateway-subnettet ikkje er eit arbeidslastsubnett med eit spesielt namn. Det er adressereservasjonen for administrerte gateway-forekomstar, og Azure vil avvise gatewayen viss reservasjonen er feil.

Start med adresserommet

Skriv VNet-prefikset, arbeidslastsubnetta og gateway-reservasjonen på éi line før du tastar noko. Eit VNet på 10.60.0.0/16 har plass; vel eit intervall på slutten slik at veksten i arbeidslaster held seg samanhengande.

Til dømes lèt 10.60.255.192/26 64 adresser vere att til gatewayen medan arbeidslaster blir i 10.60.0.0/20. Det er eit døme på adresseplanlegging, ikkje eit løfte om storleik. Microsoft krev for tida /27 eller større for VPN-gatewayar som ikkje er Basic, der større betyr fleire adresser: ein /26 gir 64, medan ein /28 gir 16. Rund opp, aldri ned, medan adresseplanen framleis bevegar seg.

Opprett subnettet med det nøyaktige namnet

I portalen legg du til eit subnett og skriv namnet GatewaySubnet nøyaktig, stor G og stor S, utan mellomrom eller suffiks. Azure samanliknar den strengen, så Gateway-Subnet eller gateway gir eit subnett som gatewaytenesta ikkje brukar.

Det same trinnet frå CLI, som er lettare å skrive inn i ein 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 vere tomt. Ingen VM, ingen privat endepunkt, inga tenestedelegering. Viss noko allereie bur der, mislukkast distribusjonen, og feilen nemner sjeldan ressursen som står i vegen, så sjekk ressurslista til subnettet før du byrjar.

Hald det administrerte subnettet fritt for arbeidslastreglar

Ikkje knyt ei nettverkssikkerheitsgruppe til dette subnettet; Microsoft merkjer det som ikkje støtta. Ikkje knyt ei rutetabell der standardruta sender 0.0.0.0/0 ein eller annan stad, fordi det kan øydeleggje gatewaydrifta, og hald gateway-ruteutbreiinga på.

Legg tilgangsavgrensingane du faktisk ønskte på arbeidslastsubnettet eller ved ein inspeksjonsgrense. Å handsame GatewaySubnet som eit vanleg subnett er feilen som gir ein gateway som blir distribuert reint og deretter ikkje slepp gjennom trafikk.

Tvungen tunnellering har sin eigen dokumenterte design. Ei improvisert standardrute på gateway-subnettet er det ikkje.

Sjekk avhengnadene portalen ikkje viser

Før du trykkjer opprett, gå gjennom lista: nøyaktig namn, prefiks inne i VNet-rommet, inga overlapping med lokale område, ingen arbeidslastressursar inni, ingen NSG og inga rutetabell med ei standardrute. Kvar av desse har øydelagt ein ekte distribusjon. Stadfest deretter den breiare designen: den lokale nettverksgatewayen for den lokale sida, adresseromma du forventar å rute, og om aktiv-aktiv eller sameksistens er planlagt. Dei vala endrar samtalen om storleik, og dei er mykje billegare å avgjere no.

Azure-referansen for gatewayinnstillingar er sida du siterer når nokon spør kvifor subnettet ikkje kan romme ein VM.

Viss gatewayen allereie finst

Å endre storleik på eller erstatte eit gateway-subnett er ikkje ei maskeredigering. Sjekk først den støtta endringsprosedyren for SKU-en og generasjonen til gatewayen, og list dei avhengige objekta: tilkoplingar, offentlege IP-ar, ruting og eventuelle krav til gjenoppretting.

Viss prosedyren krev at gatewayen blir gjenskapt, planlegg det som ein tenestemigrasjon med eit vindauge og ei tilbakerulling. Noter reservasjonen du valde, grunngivinga for storleiken og reglane du medvite ikkje knytte til, slik at neste gjennomgang ikkje reparerer det tomme subnettet ved å leggje til ein NSG.