په Azure کې د GatewaySubnet تنظیم: د ګیټوې مخکې يې ځای خوندي کړئ

په پورټل کې مجازي شبکه پرانیزئ او د فرعي شبکې پاڼې ته له لاس وړلو مخکې د پتو ځای وګورئ. که هغه /24 لا دمخه د کاري بار فرعي شبکو ته ووېشل شوی او هېڅ تش نه وي، د /27 د خوندي کولو لپاره ځای نشته، او په پای کې به یا بیا ووېشئ یا VNet پراخه کړئ، چې دا بله بدلون دی د بلې کتنې سره. لومړی ځای وټاکئ، بیا فرعي شبکه جوړه کړئ.

دا ترتیب مهم دی ځکه چې د ګیټوې فرعي شبکه د ځانګړي نوم لرونکې کاري بار فرعي شبکه نه ده. دا د مدیریت شوو ګیټوې بېلګو لپاره د پتو خوندي کول دي، او Azure به ګیټوې رد کړي که خوندي کول غلط وي.

له پتو ځای څخه پیل وکړئ

له هر څه لیکلو مخکې د VNet مخکښ، کاري بار فرعي شبکې او د ګیټوې خوندي کول په یوه کرښه کې ولیکئ. په 10.60.0.0/16 باندې VNet ځای لري؛ په پای کې یوه رینج وټاکئ تر څو د کاري بار ودې دوام ولري.

د بېلګې په توګه، 10.60.255.192/26 د ګیټوې لپاره 64 پتې پرېږدي او کاري بارونه په 10.60.0.0/20 کې پاتې کېږي. دا د پتو د پلان بېلګه ده، د اندازې ژمنه نه. Microsoft اوس مهال د غیر Basic VPN ګیټوې لپاره /27 یا لوی غواړي، چې لوی یې معنا ډېر پتې: /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 نه، او د اصلي لارې لرونکی د لارښوونې جدول نه. له دې هر یوې ریښتینی ځای پرځای کول مات کړي دي. بیا پراخ ډیزاین تایید کړئ: د محلي اړخ لپاره محلي شبکې ګیټوې، هغه پته ځایونه چې تمه لرئ لارښوونه یې وکړئ، او ایا فعال-فعال یا هم‌ژوندي پلان شوې ده. هغه انتخابونه د اندازې خبرې بدلوي، او اوس یې فیصله کول ډېر ارزان دي.

کله چې څوک وپوښتي چې فرعي شبکه ولې VM نه شي ساتلی، هغه پاڼه چې حواله ورته کوئ د Azure ګیټوې تنظیماتو مرجع ده.

که ګیټوې لا دمخه شتون ولري

د ګیټوې فرعي شبکې اندازه بدلول یا یې بدلول د ماسک سمون نه دی. لومړی د ګیټوې SKU او نسل لپاره ملاتړ شوې بدلون کړنلاره وګورئ، او تړلي توکي لیست کړئ: نښلونې، عامه IPونه، لارښوونه او هر ډول بیا رغونه غوښتنه.

که کړنلاره د ګیټوې بیا جوړول غواړي، د کړکۍ او بیرته تګ سره یې د خدمت لېږد په توګه پلان کړئ. هغه خوندي کول چې ټاکلي، د اندازې دلیل او هغه قواعد چې په قصد یې نه دي نښلولي ولیکئ، تر څو بل کتونکی په NSG اضافه کولو تشه فرعي شبکه سمه نه کړي.