Otvorite virtualnu mrežu na portalu i pogledajte adresni prostor prije nego što dirnete ploču podmreže. Ako je taj /24 već podijeljen na radne podmreže i ništa nije slobodno, nema mjesta za rezervaciju /27 i na kraju ćete morati ili ponovno dijeliti ili proširiti VNet, što je druga promjena s drugim pregledom. Najprije odredite prostor, a zatim stvorite podmrežu.

Taj je redoslijed važan jer podmreža pristupnika nije radna podmreža s posebnim nazivom. To je rezervacija adresa za upravljane instance pristupnika i Azure će odbiti pristupnik ako je rezervacija pogrešna.

Počnite s adresnim prostorom

Zapišite prefiks VNet-a, radne podmreže i rezervaciju pristupnika u jedan redak prije nego što išta upišete. VNet na 10.60.0.0/16 ima mjesta; odaberite raspon na kraju kako bi rast radnih opterećenja ostao neprekinut.

Na primjer, 10.60.255.192/26 ostavlja 64 adrese za pristupnik, dok radna opterećenja ostaju u 10.60.0.0/20. To je primjer planiranja adresa, a ne obećanje o veličini. Microsoft trenutačno zahtijeva /27 ili veći za ne-Basic VPN pristupnike, gdje veći znači više adresa: /26 daje 64, a /28 daje 16. Zaokružujte prema gore, nikada prema dolje, dok se plan adresa još mijenja.

Stvorite podmrežu s točnim nazivom

Na portalu dodajte podmrežu i upišite naziv GatewaySubnet točno, veliko G i veliko S, bez razmaka ili sufiksa. Azure uspoređuje taj niz, pa Gateway-Subnet ili gateway stvara podmrežu koju servis pristupnika neće koristiti.

Isti korak iz CLI-ja, koji je lakše staviti na pregled:

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

Ostavite podmrežu praznom. Bez VM-a, bez privatnog endpointa, bez delegiranja servisa. Ako nešto već tamo živi, implementacija ne uspijeva i pogreška rijetko navodi resurs koji smeta, zato prije početka provjerite popis resursa podmreže.

Držite upravljanu podmrežu slobodnom od pravila za radna opterećenja

Ne prikvačite mrežnu sigurnosnu grupu na ovu podmrežu; Microsoft to označava kao nepodržano. Ne pridružujte tablicu usmjeravanja čija zadana ruta šalje 0.0.0.0/0 negdje, jer to može prekinuti rad pristupnika, i držite propagaciju ruta pristupnika uključenom.

Postavite ograničenja pristupa koja ste doista željeli na radnu podmrežu ili na granicu inspekcije. Tretiranje GatewaySubnet-a kao uobičajene podmreže pogreška je koja stvara pristupnik koji se čisto implementira i zatim ne propušta promet.

Prisilno tuneliranje ima vlastiti dokumentirani dizajn. Improvizirana zadana ruta na podmreži pristupnika to nije.

Provjerite ovisnosti koje portal ne prikazuje

Prije nego što pritisnete stvori, prođite popis: točan naziv, prefiks unutar prostora VNet-a, bez preklapanja s lokalnim rasponima, bez resursa radnih opterećenja unutra, bez NSG-a i bez tablice usmjeravanja sa zadanom rutom. Svaka od tih stvari prekinula je stvarnu implementaciju. Zatim potvrdite širi dizajn: lokalni mrežni pristupnik za lokalnu stranu, adresne prostore koje očekujete usmjeravati i je li planiran aktivno-aktivni način ili supostojanje. Ti izbori mijenjaju razgovor o veličini i mnogo ih je jeftinije riješiti sada.

Stranica Referenca za postavke pristupnika u Azureu je ono na što se pozivate kad netko pita zašto podmreža ne može primiti VM.

Ako pristupnik već postoji

Promjena veličine ili zamjena podmreže pristupnika nije uređivanje maske. Najprije provjerite podržani postupak promjene za SKU i generaciju pristupnika te navedite ovisne objekte: veze, javne IP adrese, usmjeravanje i sve zahtjeve za oporavak.

Ako postupak zahtijeva ponovno stvaranje pristupnika, planirajte to kao migraciju servisa s prozorom i vraćanjem. Zabilježite rezervaciju koju ste odabrali, razlog veličine i pravila koja namjerno niste prikvačili, kako sljedeći recenzent ne bi popravio praznu podmrežu dodavanjem NSG-a.

Povezani članci