Наладка GatewaySubnet у Azure: зарэзервуйце яго да шлюза

Адкрыйце віртуальную сетку ў партале і паглядзіце на прастору адрасоў, перш чым кранаць панэль падсеткі. Калі той /24 ужо падзелены на падсеткі працоўных нагрузкаў і вольнага месца не засталося, для рэзерву /27 месца няма, і вы ў рэшце рэшт або перападзеліце, або пашырыце VNet, а гэта іншае змяненне з іншым разглядам. Спачатку вызначце прастору, потым стварайце падсетку.

Гэты парадак важны, бо падсетка шлюза — не падсетка працоўнай нагрузкі са спецыяльнай назвай. Гэта рэзерв адрасоў для кіраваных асобнікаў шлюза, і Azure адмовіць у шлюзе, калі рэзерв няправільны.

Пачніце з прасторы адрасоў

Запішыце прэфікс VNet, падсеткі працоўных нагрузкаў і рэзерв шлюза ў адзін радок, перш чым нешта ўводзіць. VNet на 10.60.0.0/16 мае месца; выберыце дыяпазон у канцы, каб рост працоўных нагрузкаў заставаўся бесперапынным.

Напрыклад, 10.60.255.192/26 пакідае 64 адрасы для шлюза, а працоўныя нагрузкі застаюцца ў 10.60.0.0/20. Гэта прыклад планавання адрасоў, а не абяцанне памеру. Microsoft цяпер патрабуе /27 або большы для не-Basic VPN-шлюзаў, дзе большы азначае больш адрасоў: /26 дае 64, а /28 дае 16. Акругляйце ўверх, ніколі ўніз, пакуль план адрасоў яшчэ рухаецца.

Стварыце падсетку з дакладным імем

У партале дадайце падсетку і ўвядзіце імя GatewaySubnet дакладна, з вялікімі G і S, без прабелаў і суфікса. Azure супастаўляе гэты радок, таму Gateway-Subnet або gateway стварае падсетку, якую служба шлюза не будзе выкарыстоўваць.

Той жа крок з CLI, які прасцей зафіксаваць у разглядзе:

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

Пакіньце падсетку пустой. Ніякай VM, ніякага прыватнага endpoint, ніякай дэлегацыі службы. Калі там ужо нешта ёсць, разгортванне праваліцца, і памылка рэдка называе рэсурс, які замінае, таму перад пачаткам праверце спіс рэсурсаў падсеткі.

Трымайце кіраваную падсетку свабоднай ад правілаў працоўных нагрузкаў

Не далучайце групу сеткавай бяспекі да гэтай падсеткі; Microsoft пазначае гэта як неподтрымліванае. Не звязвайце табліцу маршрутаў, чый маршрут па змаўчанні накіроўвае 0.0.0.0/0 некуды, бо гэта можа парушыць працу шлюза, і трымайце распаўсюджванне маршрутаў шлюза ўключаным.

Змясціце абмежаванні доступу, якія вы насамрэч хацелі, на падсетку працоўнай нагрузкі або на мяжу інспекцыі. Стаўленне да GatewaySubnet як да звычайнай падсеткі — гэта памылка, якая стварае шлюз, што разгортваецца чыста і потым не прапускае ніякі трафік.

Прымусовае тунеляванне мае свой дакументаваны дызайн. Імправізаваны маршрут па змаўчанні на падсетцы шлюза — гэта не ён.

Праверце залежнасці, якія партал не паказвае

Перш чым націснуць стварыць, прайдзіце па спісе: дакладнае імя, прэфікс унутры прасторы VNet, адсутнасць перакрыцця з лакальнымі дыяпазонамі, адсутнасць рэсурсаў працоўных нагрузак унутры, адсутнасць NSG і адсутнасць табліцы маршрутаў з маршрутам па змаўчанні. Кожнае з гэтага ламала рэальнае разгортванне. Затым пацвердзіце шырэйшы дызайн: лакальны сеткавы шлюз для лакальнага боку, прасторы адрасоў, якія вы збіраецеся маршрутызаваць, і ці плануецца актыўна-актыўны рэжым або суіснаванне. Гэтыя выбары змяняюць размову пра памер, і вырашаць іх цяпер нашмат танней.

Старонка Даведка па наладках шлюза Azure — гэта тое, на што спасылаюцца, калі хтосьці пытае, чаму падсетка не можа змясціць VM.

Калі шлюз ужо існуе

Змена памеру або замена падсеткі шлюза — гэта не праўка маскі. Спачатку праверце падтрымліваную працэдуру змены для SKU і пакалення шлюза, а таксама пералічыце залежныя аб’екты: падключэнні, публічныя IP, маршрутызацыю і любыя патрабаванні да аднаўлення.

Калі працэдура патрабуе перастварэння шлюза, плануйце гэта як міграцыю службы з акном і адкатам. Запішыце абраны рэзерв, прычыну памеру і правілы, якія вы свядома не далучылі, каб наступны рэцэнзент не выправіў пустую падсетку, дадаўшы NSG.