Pag-set up ng GatewaySubnet sa Azure: ireserba ito bago ang gateway

Buksan ang virtual network sa portal at tingnan ang espasyo ng address bago hawakan ang subnet blade. Kung ang /24 na iyon ay nahahati na sa mga subnet ng workload na walang natitirang bakante, walang puwang para sa /27 reservation, at sa huli ay muling maghahati ka o palalawakin ang VNet, na ibang pagbabago na may ibang review. Itakda muna ang espasyo, pagkatapos ay gumawa ng subnet.

Mahalaga ang pagkakasunod-sunod na iyon dahil ang gateway subnet ay hindi subnet ng workload na may espesyal na pangalan. Ito ang reserbasyon ng address para sa mga pinamamahalaang instance ng gateway, at tatanggihan ng Azure ang gateway kung mali ang reserbasyon.

Magsimula sa espasyo ng address

Isulat ang VNet prefix, ang mga subnet ng workload at ang reserbasyon ng gateway sa isang linya bago mag-type ng anuman. May puwang ang VNet sa 10.60.0.0/16; pumili ng saklaw sa dulo para manatiling magkadikit ang paglaki ng workload.

Halimbawa, nag-iiwan ang 10.60.255.192/26 ng 64 address para sa gateway habang nananatili ang workload sa 10.60.0.0/20. Halimbawa ito ng pagpaplano ng address, hindi pangako sa laki. Sa ngayon, hinihiling ng Microsoft ang /27 o mas malaki para sa mga gateway ng VPN na hindi Basic, kung saan ang mas malaki ay nangangahulugang mas maraming address: nagbibigay ang /26 ng 64, samantalang nagbibigay ang /28 ng 16. Bilugan pataas, huwag kailanman pababa, habang gumagalaw pa ang plano ng address.

Gumawa ng subnet gamit ang eksaktong pangalan

Sa portal, magdagdag ng subnet at i-type ang pangalang GatewaySubnet nang eksakto, malaking G at malaking S, walang espasyo o suffix. Inihahambing ng Azure ang string na iyon, kaya ang Gateway-Subnet o gateway ay gumagawa ng subnet na hindi gagamitin ng serbisyo ng gateway.

Ang parehong hakbang mula sa CLI, na mas madaling isulat sa isang review:

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

Iwanang walang laman ang subnet. Walang VM, walang pribadong endpoint, walang delegasyon ng serbisyo. Kung may nakatira na roon, nabibigo ang deployment at bihirang pangalanan ng error ang resource na humaharang, kaya suriin ang listahan ng resource ng subnet bago magsimula.

Panatilihing malaya ang pinamamahalaang subnet sa mga patakaran ng workload

Huwag maglakip ng network security group sa subnet na ito; minamarkahan ito ng Microsoft bilang hindi sinusuportahan. Huwag iugnay ang routing table na ang default route ay nagpapadala ng 0.0.0.0/0 sa kung saan, dahil maaaring sirain nito ang operasyon ng gateway, at panatilihing naka-enable ang pagpapalaganap ng ruta ng gateway.

Ilagay ang mga paghihigpit sa access na talagang gusto mo sa subnet ng workload o sa hangganan ng inspeksyon. Ang pagtrato sa GatewaySubnet na parang ordinaryong subnet ang pagkakamaling gumagawa ng gateway na malinis na naka-deploy at pagkatapos ay wala nang pinapasang trapiko.

May sariling dokumentadong disenyo ang forced tunneling. Ang improvised na default route sa subnet ng gateway ay hindi iyon.

Suriin ang mga dependency na hindi ipinapakita ng portal

Bago pindutin ang gumawa, daanan ang listahan: eksaktong pangalan, prefix sa loob ng espasyo ng VNet, walang overlap sa mga lokal na saklaw, walang resource ng workload sa loob, walang NSG, at walang routing table na may default route. Bawat isa sa mga ito ay nakasira ng tunay na deployment. Pagkatapos, kumpirmahin ang mas malawak na disenyo: ang local network gateway para sa lokal na bahagi, ang mga espasyo ng address na inaasahan mong i-route, at kung aktibo-aktibo o coexistence ang pinlano. Binabago ng mga pagpipiliang iyon ang usapan tungkol sa laki, at mas mura itong ayusin ngayon.

Ang reference ng mga setting ng gateway sa Azure ang pahinang sipiin kapag may nagtanong kung bakit hindi kayang maglagay ng VM ang subnet.

Kung mayroon nang gateway

Ang pagbabago ng laki o pagpapalit ng subnet ng gateway ay hindi pag-edit ng mask. Suriin muna ang sinusuportahang pamamaraan ng pagbabago para sa SKU at henerasyon ng gateway, at ilista ang mga dependent na object: mga koneksyon, pampublikong IP, routing at anumang kinakailangan sa pagbawi.

Kung kailangan ng pamamaraan na muling gawin ang gateway, planuhin ito bilang paglilipat ng serbisyo na may window at rollback. Itala ang reserbasyong pinili mo, ang dahilan ng laki at ang mga patakarang sadyang hindi mo inilakip, para hindi ayusin ng susunod na reviewer ang walang lamang subnet sa pamamagitan ng pagdaragdag ng NSG.