Azure GatewaySubnet sąranka: rezervuokite jį prieš vartus

Atidarykite virtualų tinklą portale ir pažiūrėkite į adresų erdvę, prieš liesdami potinklio skydelį. Jei tas /24 jau suskaidytas į darbo krūvio potinklius ir nieko laisvo neliko, /27 rezervacijai vietos nėra, ir galiausiai arba skaidysite iš naujo, arba plėsite VNet, o tai jau kitas pakeitimas su kita peržiūra. Pirmiausia nustatykite erdvę, tada kurkite potinklį.

Ši tvarka svarbi, nes vartų potinklis nėra darbo krūvio potinklis su specialiu pavadinimu. Tai adresų rezervacija valdomiems vartų egzemplioriams, ir Azure atsisakys vartų, jei rezervacija neteisinga.

Pradėkite nuo adresų erdvės

Prieš ką nors įvesdami, vienoje eilutėje surašykite VNet prefiksą, darbo krūvio potinklius ir vartų rezervaciją. 10.60.0.0/16 VNet turi vietos; pasirinkite diapazoną pabaigoje, kad darbo krūvio augimas liktų ištisinis.

Pavyzdžiui, 10.60.255.192/26 palieka 64 adresus vartams, o darbo krūviai lieka 10.60.0.0/20. Tai adresų planavimo pavyzdys, o ne dydžio pažadas. Microsoft šiuo metu reikalauja /27 ar didesnio ne Basic VPN vartams, kur didesnis reiškia daugiau adresų: /26 duoda 64, o /28 duoda 16. Apvalinkite aukštyn, niekada žemyn, kol adresų planas dar juda.

Sukurkite potinklį tiksliu pavadinimu

Portale pridėkite potinklį ir įveskite pavadinimą GatewaySubnet tiksliai, didžioji G ir didžioji S, be tarpų ar priesagos. Azure lygina šią eilutę, todėl Gateway-Subnet arba gateway sukuria potinklį, kurio vartų tarnyba nenaudos.

Tas pats žingsnis iš CLI, jį lengviau įrašyti į peržiūrą:

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

Palikite potinklį tuščią. Jokio VM, jokio privataus endpoint, jokio paslaugos delegavimo. Jei ten jau kažkas gyvena, diegimas nepavyksta, o klaida retai įvardija kliudantį išteklių, todėl prieš pradėdami patikrinkite potinklio išteklių sąrašą.

Laikykite valdomą potinklį be darbo krūvio taisyklių

Neprikabinkite prie šio potinklio tinklo saugos grupės; Microsoft tai žymi kaip nepalaikomą. Nesusiekite maršrutų lentelės, kurios numatytasis maršrutas siunčia 0.0.0.0/0 kažkur, nes tai gali sulaužyti vartų veikimą, ir palikite įjungtą vartų maršrutų sklaidą.

Tikrai norimus prieigos apribojimus dėkite į darbo krūvio potinklį arba į patikros ribą. Elgtis su GatewaySubnet kaip su įprastu potinkliu yra klaida, dėl kurios vartai įdiegiami švariai ir po to nepraleidžia jokio srauto.

Priverstinis tuneliavimas turi savo dokumentuotą dizainą. Improvizuotas numatytasis maršrutas vartų potinklyje nėra tai.

Patikrinkite priklausomybes, kurių portalas nerodo

Prieš spaudžiant kurti, pereikite sąrašą: tikslus pavadinimas, prefiksas VNet erdvėje, jokio persidengimo su vietiniais diapazonais, viduje jokių darbo krūvio išteklių, jokios NSG ir jokios maršrutų lentelės su numatytuoju maršrutu. Kiekvienas iš jų yra sulaužęs realų diegimą. Tada patvirtinkite platesnį dizainą: vietinės pusės vietinis tinklo vartai, adresų erdvės, kurias ketinate maršrutizuoti, ir ar planuojamas aktyvus-aktyvus režimas, ar sambūvis. Šie pasirinkimai keičia pokalbį apie dydį, ir juos sutvarkyti dabar daug pigiau.

Azure vartų nustatymų nuoroda yra puslapis, į kurį remiamasi, kai kas nors klausia, kodėl potinklis negali talpinti VM.

Jei vartai jau egzistuoja

Vartų potinklio dydžio keitimas arba pakeitimas nėra kaukės redagavimas. Pirmiausia patikrinkite palaikomą keitimo procedūrą vartų SKU ir kartai, ir išvardykite priklausomus objektus: ryšius, viešus IP, maršrutizavimą ir bet kokius atkūrimo reikalavimus.

Jei procedūra reikalauja iš naujo sukurti vartus, planuokite tai kaip paslaugos migraciją su langu ir atsukimu atgal. Užrašykite pasirinktą rezervaciją, dydžio priežastį ir taisykles, kurių sąmoningai neprikabinote, kad kitas peržiūros atlikėjas nesutaisytų tuščio potinklio pridėdamas NSG.