Nastavitev GatewaySubnet v Azure: rezervirajte ga pred prehodom

Odprite virtualno omrežje na portalu in si oglejte naslovni prostor, preden se dotaknete plošče podomrežja. Če je ta /24 že razdeljen na podomrežja delovnih obremenitev in ni nič prosto, ni prostora za rezervacijo /27 in na koncu boste bodisi znova razdelili bodisi razširili VNet, kar je druga sprememba z drugim pregledom. Najprej določite prostor, nato ustvarite podomrežje.

Ta vrstni red je pomemben, ker podomrežje prehoda ni podomrežje delovne obremenitve s posebnim imenom. To je rezervacija naslovov za upravljane primerke prehoda, in Azure bo prehod zavrnil, če je rezervacija napačna.

Začnite z naslovnim prostorom

Preden karkoli vtipkate, zapišite predpono VNet, podomrežja delovnih obremenitev in rezervacijo prehoda v eno vrstico. VNet na 10.60.0.0/16 ima prostor; izberite obseg na koncu, da rast delovnih obremenitev ostane sklenjena.

Na primer, 10.60.255.192/26 pusti 64 naslovov za prehod, medtem ko delovne obremenitve ostanejo v 10.60.0.0/20. To je primer načrtovanja naslovov, ne obljuba o velikosti. Microsoft trenutno zahteva /27 ali večji za prehode VPN, ki niso Basic, kjer večji pomeni več naslovov: /26 jih da 64, /28 pa 16. Zaokrožujte navzgor, nikoli navzdol, dokler se načrt naslovov še premika.

Ustvarite podomrežje s točnim imenom

Na portalu dodajte podomrežje in vtipkajte ime GatewaySubnet točno, velika G in velika S, brez presledkov ali pripone. Azure primerja ta niz, zato Gateway-Subnet ali gateway ustvari podomrežje, ki ga storitev prehoda ne bo uporabila.

Isti korak iz CLI, ki ga je lažje zapisati v pregled:

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

Pustite podomrežje prazno. Brez VM, brez zasebne končne točke, brez delegiranja storitve. Če tam že kaj živi, uvajanje ne uspe in napaka le redko navede vir, ki je v napoto, zato pred začetkom preverite seznam virov podomrežja.

Ohranjajte upravljano podomrežje brez pravil delovnih obremenitev

Na to podomrežje ne pritrdite varnostne skupine omrežja; Microsoft to označuje kot nepodprto. Ne povežite usmerjevalne tabele, katere privzeta pot pošilja 0.0.0.0/0 nekam, ker lahko to pokvari delovanje prehoda, in ohranite omogočeno širjenje poti prehoda.

Omejitve dostopa, ki ste jih resnično želeli, postavite na podomrežje delovne obremenitve ali na mejno točko pregleda. Obravnavanje GatewaySubnet kot običajnega podomrežja je napaka, ki ustvari prehod, ki se čisto uvede in nato ne prepusti nobenega prometa.

Prisilno tuneliranje ima svoj dokumentiran načrt. Improvizirana privzeta pot na podomrežju prehoda to ni.

Preverite odvisnosti, ki jih portal ne prikaže

Preden pritisnete ustvari, pojdite po seznamu: točno ime, predpona znotraj prostora VNet, brez prekrivanja z lokalnimi obsegi, brez virov delovnih obremenitev znotraj, brez NSG in brez usmerjevalne tabele s privzeto potjo. Vsaka od teh je že pokvarila resnično uvajanje. Nato potrdite širši načrt: lokalni omrežni prehod za lokalno stran, naslovni prostori, ki jih nameravate usmerjati, in ali je načrtovan aktivni-aktivni način ali soobstoj. Te odločitve spremenijo pogovor o velikosti in veliko ceneje jih je urediti zdaj.

Referenca za nastavitve prehoda Azure je stran, na katero se sklicujete, ko kdo vpraša, zakaj podomrežje ne more gostiti VM.

Če prehod že obstaja

Spreminjanje velikosti ali zamenjava podomrežja prehoda ni urejanje maske. Najprej preverite podprti postopek spremembe za SKU in generacijo prehoda, nato naštejte odvisne objekte: povezave, javne IP naslove, usmerjanje in morebitne zahteve po obnovitvi.

Če postopek zahteva ponovno ustvarjanje prehoda, ga načrtujte kot migracijo storitve z oknom in vrnitvijo. Zabeležite rezervacijo, ki ste jo izbrali, razlog za velikost in pravila, ki jih namenoma niste pritrdili, da naslednji pregledovalec ne bo popravil praznega podomrežja z dodajanjem NSG.