Azure P2S VPN د شخصي پای ټکي نوم نه شي حل کولی

تاسو point-to-site تونل نښلوئ، شخصي پتې ته ping کوئ، اپلیکیشن خلاصوئ او پرځای یې 403 یا د سند تېروتنه ترلاسه کوئ. دواړه نښې DNS ته اشاره کوي، مګر دا بېلابېل خرابې دي: یوه یې مانا دا ده چې کاروونکي عامه پته حل کړه، بله یې مانا دا ده چې شخصي پته یې حل کړه او بیا یې داسې نوم وړاندې کړ چې سند یې نه پوښي. لاندې پلټنې په ترتیب سره وکړئ او په لومړنۍ ناکامۍ ودرېږئ، ځکه چې یوه hosts ننوتنه یا په کیش کې خوندي ځواب کولی شي هرې راتلونکې پلټنې ته د غلط دلیل له مخې بریالیتوب ورکړي. زه دا ترتیب زما د VPN پروفایلونو ترڅنګ په یوه متن فایل کې ساتم، ځکه چې سمون په تونل کې هېڅ نه بدلوي او په هغه څه کې چې کاروونکی یې پوهېږي هر څه بدلوي.

د هغې پتې څخه پیل وکړئ چې کاروونکی یې واقعاً ترلاسه کوي

له اپلیکیشن سره د باور کولو پرځای له حل کوونکي څخه مستقیم وپوښتئ. په Windows کې، nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net ښیي چې کاروونکي کوم لید ترلاسه کړی. عامه ځواب مانا دا ده چې لاندې هېڅ شی به پای ټکي ته ونه رسېږي؛ د پای ټکي شخصي پته مانا دا ده چې DNS پای ته رسېدلی او بله پلټنه خپله اړیکه ده.

شخصي پای ټکی د خدمت نوم نه بدلوي. حساب یا اپلیکیشن خپل معمول بشپړ وړ نوم ساتي، او پای ټکی یوازې هغه پته بدلوي چې دا نوم د مجازي شبکې دننه کاروونکو لپاره هغې ته حل کېږي. له همدې امله هماغه کوربه نوم د شبکې له VM څخه په شخصي ډول او له هغه لیپ ټاپ څخه چې کله یې شخصي لید نه دی ترلاسه کړی په عامه ډول حل کېږي.

د تونل څخه مخکې زون، تړاو او ریکارډ وګورئ

درې شرطونه باید یوځای پوره شي: شخصي زون شته، له هغې مجازي شبکې سره تړلی چې VPN ګېټوې او کاروونکي Azure ته ننوځي، او په کې د پای ټکي لپاره A ریکارډ شته چې شخصي پتې ته اشاره کوي. که زون له بې اړیکې شبکې سره ونښلوئ، ګېټوې به عامه ریکارډ حل کول جاري وساتي، په داسې حال کې چې د تونل هر څه روغ ښکاري.

د زون نومونه خدمتونو پورې اړه لري، نه په عمومي ډول شخصي تړاوونو ته. App Service معمولاً privatelink.azurewebsites.net کاروي، زېرمه او SQL خپل نوم ځایونه لري، او د بل خدمت زون پور اخیستل داسې زون جوړوي چې شته خو هېڅ ګټور ځواب نه ورکوي.

کاروونکي ته هغه حل کوونکی ورکړئ چې هغه واقعاً ورته رسېدلی شي

168.63.129.16 د Azure مجازي ماشینونو څخه ځواب ورکوي او د point-to-site تونل بلې خوا ته د یوه لیپ ټاپ لپاره DNS سرور نه دی. کاروونکي ته د تونل له لارې د لاسرسي وړ حل کوونکی ته اړتیا ده: د Azure DNS Private Resolver داخلي پای ټکی، د مجازي شبکې دننه لېږدونکی، یا په VPN کاروونکي پروفایل کې وړونکي DNS سرور ننوتنې، ترڅو کاروونکی مجازي شبکې ته مستقیم وپوښتي.

تنظیم شوی خو د لاسرسي بهر حل کوونکی په بشپړه توګه د هېڅ حل کوونکي په څېر چلند کوي، او نښه غلط ځواب نه بلکې وخت ختمېدل دي، نو ځکه د اور دېوال ستونزه لوستل کېږي. هغه د هغې پوښتنې سره وازموئ چې تونل یې وړل کوي، نه د عامه نوم سره چې په ځایي تړاو به هرومرو بریالی شوی و.

که د تنظیماتو د ټېل وهلو پرځای لېږدوئ، هغه نوم ځای ولېږدوئ چې شخصي زون یې لري، د ټول azurewebsites.net پرځای privatelink.azurewebsites.net. هغه شرطي لېږدونکی چې ټول مورني پسوند تېروي د خدمت هره پلټنه Azure ته لېږي، هغه هم چې باید ځایي پاتې شي.

هغه نوم وکاروئ چې سند د هغې لپاره صادر شوی

کله چې پته سمه شي، دوهمه خرابي ښکاري. زېرمه او App Service privatelink لقب خپروي، او هغه لقب اړینه نه ده چې په سند کې نوم وي. privatelink.blob.core.windows.net ته لېږل شوی AzCopy پورته کول په اعتبارسنجۍ کې ناکام شو؛ هماغه پورته کول <account>.blob.core.windows.net/<container> ته شخصي پتې ته حل شو او پاس شو، نو له هېڅ مخښکاږلو پرته په شخصي لاره پاتې شو.

دا قاعده په براوزر کې او د App Service لپاره هم پلي کېږي: له هغه کوربه نوم سره ونښلوئ چې سند یې پوښي او DNS ته اجازه ورکړئ چې شخصي پته برابره کړي. د اعتبارسنجۍ له مخښکاږلو څخه ډډه وکړئ، ځکه چې د نوم ایښودنې تېروتنه امنیتي پسټلو ته اړوي. بریالی ping لاره ثابتوي او د لاس ورکولو دننه د نوم په اړه هېڅ نه وایي، نو ځکه دا جلا پلټنې پاتې کېږي.

د هرې طبقې د جلا کولو څلور ګامه ترتیب

1. باوري کړئ چې VPN کاروونکي د point-to-site حوض څخه پته او د پای ټکي شخصي پتې ته لاره لري.
2. هغه دقیق نوم حل کړئ چې اپلیکیشن یې کاروي او ځواب د پای ټکي له پتې سره پرتله کړئ.
3. په خدمت پورټ کې له پای ټکي سره TCP اړیکه پرانیزئ، بیا په هغې اړیکه کې وړاندې شوی د سند نوم ولولئ.
4. یوازې اوس اجازه وګورئ، ځکه چې کار کوونکې لاره او معتبر سند لا هم سرچینې ته لاسرسی نه ورکوي.

کله چې پته سمه وي او اړیکه رد شي، دا DNS ته نه بلکې د شبکې امنیتي ګروپ یا د شخصي پای ټکي د اړیکې حالت ته اشاره کوي، نو د حل کوونکي تنظیماتو له بیا سمون څخه مخکې هغه وګورئ. د TLS نوم ناسمون نه تاسو URL کې کوربه نوم او د سند subject ته بېرته لېږي. د حل کولو پایله، د سند نوم او دقیق URL یوځای وساتئ؛ دا درې ارزښتونه ډېری دې پېښې پرته له دې چې ګېټوې ته لاس ووهئ بیانوي.

د کنټرول په توګه د مجازي شبکې دننه VM وکاروئ. که نوم هلته شخصي او له تونل څخه عامه حل شي، زون او ریکارډ سم دي او یوازینی توپیر د کاروونکي د حل کوونکي لاره ده، چې تصدیق یې د پای ټکي په ترتیب باندې د بل پړاو څخه ګړندی دی.

کاروونکي هم کیش کوي. هغه ریکارډ چې لس دقیقې مخکې یې په عامه ډول ځواب ویلی، د زون له سمولو وروسته هم ځواب وایي، نو د بیا ازموینې مخکې کیش تش کړئ. په Windows کې، ipconfig /flushdns د کاروونکي کیش پاکوي؛ د نوم حل کولو د تګلارې قواعد پاتې کېږي، ټاکي چې کوم پسوند کوم سرور ته ځي، او کېدای شي نوم ځای هغه حل کوونکي ته لېږلو ته دوام ورکړي چې تاسو همدا اوس بدل کړ.

hosts ننوتنه چېرته ځای لري

د پای ټکي پته په hosts فایل کې زیاتول ښه تشخیص او بد ډیزاین دی. دا ثابتوي چې د نوم او پتې نقشه هماغه ورکه برخه ده او له هغه ګام وروسته هر څه ازموي، خو ستاسو کاروونکو ته نه ښکاري، کله چې د پای ټکي پته بدله شي ماتېږي، او هغه زون پټوي چې باید ځواب ووایي.

پاتې شوې ازموینه ننوتنه له زاړه کیش څخه هم بدتره ده، ځکه چې د تېروتنې د لوري له مخې کېدای شي سمه شوې لاره ماتېدلې یا ماتېدلې لاره سمه شوې وښیي. د وروستي پړاو څخه مخکې یې لرې کړئ او یوازې د تولید حل کوونکي سره حل کړئ.

لنډ نومونه د لټون پسوند ته اړتیا لري او بشپړ وړ نومونه نه، نو لومړی بشپړ وړ نوم وازموئ، بیا پرېکړه وکړئ چې د کار بهیر ته د کاروونکي پروفایل له لارې ټېل وهل شوی پسوند ته اړتیا ده که نه. Microsoft په خپلو د شخصي پای ټکو DNS لارښوونو کې د هر خدمت لپاره زون نومونه او د ریکارډ بڼې مستند کوي؛ د بل خدمت څخه د زون کاپي کولو پرځای د خپل خدمت ننوتنه ولولئ.