Atveriet virtuālo tīklu portālā un apskatiet adrešu telpu, pirms pieskaraties apakštīkla panelim. Ja tas /24 jau ir sadalīts darba slodzes apakštīklos un nekas nav brīvs, /27 rezervācijai nav vietas, un beigās jūs vai nu sadalīsiet no jauna, vai paplašināsiet VNet, kas ir cita izmaiņa ar citu pārskatīšanu. Vispirms nosakiet telpu, pēc tam izveidojiet apakštīklu.

Šī secība ir svarīga, jo vārtejas apakštīkls nav darba slodzes apakštīkls ar īpašu nosaukumu. Tā ir adrešu rezervācija pārvaldītiem vārtejas eksemplāriem, un Azure atteiks vārtejai, ja rezervācija ir nepareiza.

Sāciet ar adrešu telpu

Pirms kaut ko ierakstāt, vienā rindā ierakstiet VNet prefiksu, darba slodzes apakštīklus un vārtejas rezervāciju. VNet ar 10.60.0.0/16 ir vieta; izvēlieties diapazonu beigās, lai darba slodzes pieaugums paliktu nepārtraukts.

Piemēram, 10.60.255.192/26 atstāj 64 adreses vārtejai, kamēr darba slodzes paliek 10.60.0.0/20. Tas ir adrešu plānošanas piemērs, nevis solījums par izmēru. Microsoft pašlaik pieprasa /27 vai lielāku ne-Basic VPN vārtejām, kur lielāks nozīmē vairāk adrešu: /26 dod 64, bet /28 dod 16. Noapaļojiet uz augšu, nekad uz leju, kamēr adrešu plāns vēl kustas.

Izveidojiet apakštīklu ar precīzu nosaukumu

Portālā pievienojiet apakštīklu un ierakstiet nosaukumu GatewaySubnet precīzi, lielais G un lielais S, bez atstarpēm vai sufiksa. Azure salīdzina šo virkni, tāpēc Gateway-Subnet vai gateway izveido apakštīklu, ko vārtejas pakalpojums neizmantos.

Tas pats solis no CLI, ko vieglāk ierakstīt pārskatīšanā:

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

Atstājiet apakštīklu tukšu. Nav VM, nav privāta endpoint, nav pakalpojuma deleģēšanas. Ja tur jau kaut kas dzīvo, izvietošana neizdodas un kļūda reti nosauc traucējošo resursu, tāpēc pirms sākšanas pārbaudiet apakštīkla resursu sarakstu.

Turiet pārvaldīto apakštīklu brīvu no darba slodzes noteikumiem

Nepievienojiet šim apakštīklam tīkla drošības grupu; Microsoft to atzīmē kā neatbalstītu. Nesaistiet maršrutēšanas tabulu, kuras noklusējuma maršruts sūta 0.0.0.0/0 kaut kur, jo tas var salauzt vārtejas darbību, un turiet ieslēgtu vārtejas maršrutu izplatīšanu.

Tos piekļuves ierobežojumus, ko patiešām gribējāt, lieciet uz darba slodzes apakštīkla vai uz pārbaudes robežas. Attiekties pret GatewaySubnet kā pret parastu apakštīklu ir kļūda, kas rada vārteju, kura izvietojas tīri un pēc tam nelaida cauri nekādu trafiku.

Piespiedu tunelēšanai ir savs dokumentēts dizains. Improvizēts noklusējuma maršruts uz vārtejas apakštīkla nav tas.

Pārbaudiet atkarības, ko portāls nerāda

Pirms spiest izveidot, izejiet sarakstu: precīzs nosaukums, prefikss VNet telpā, nav pārklāšanās ar vietējiem diapazoniem, iekšā nav darba slodzes resursu, nav NSG un nav maršrutēšanas tabulas ar noklusējuma maršrutu. Katrs no tiem ir salauzis reālu izvietošanu. Pēc tam apstipriniet plašāko dizainu: vietējās puses vietējā tīkla vārteja, adrešu telpas, ko plānojat maršrutēt, un vai ir plānots aktīvs-aktīvs vai līdzāspastāvēšana. Šīs izvēles maina sarunu par izmēru, un tās tagad ir daudz lētāk nokārtot.

Azure vārtejas iestatījumu atsauce ir lapa, uz ko atsaukties, kad kāds jautā, kāpēc apakštīkls nevar uzņemt VM.

Ja vārteja jau pastāv

Vārtejas apakštīkla lieluma maiņa vai aizstāšana nav maskas rediģēšana. Vispirms pārbaudiet atbalstīto maiņas procedūru vārtejas SKU un paaudzei, un uzskaitiet atkarīgos objektus: savienojumus, publiskās IP, maršrutēšanu un jebkuras atkopšanas prasības.

Ja procedūra prasa vārtejas atjaunošanu, plānojiet to kā pakalpojuma migrāciju ar logu un atritināšanu. Pierakstiet izvēlēto rezervāciju, izmēra iemeslu un noteikumus, ko apzināti nepievienojāt, lai nākamais pārskatītājs nesalabotu tukšo apakštīklu, pievienojot NSG.

Saistītie raksti