د VPN له پیل وروسته Azure VM IMDS یا WireServer ته نه رسېږي

ماشین روان دی، د VPN کلاینت وايي چې نښلول شوی، او څو دقیقې وروسته Azure agent د ناسموالي راپور ورکول پیل کوي. کله ناکله SSH ژوندی پاتې کېږي او د پورټل Run Command نه، چې خلک د لارښوونې جدول پر ځای agent ته ورټېږي. کله چې تونل پورته شو، د مېلمه خپلې لېږدونکې پرېکړې بدلې شوې، او معمولاً دوه پلیټفارم پتې لومړني قربانیان وي. زه دا د agent ناکامۍ په توګه نه، بلکې لومړی د لارښوونې نښې په توګه ګڼم.

نښه د خراب agent په څېر ښکاري

لاندې دواړه پتې د حل په توګه وړاندې کېږي، خو دوی یوه خدمت نه دی. د یو لپاره /32 کاپي کول ځکه چې د بل لپاره یې کار وکړ—په همدې توګه لنډمهاله لار د تلپاتې تنظیماتو بدلېږي چې هیڅوک یې لرې کولو زړه نلري.

هغه ترتیب چې کار کوي دا دی: لومړی تایید کړئ چې ناکامه غږ په رښتیا کومه پته نښه کوي، بیا ولولئ چې مېلمه یې څنګه حل کوي. نور هر څه اضافي ګامونو سره اټکل او اوږد بدلون کړکۍ دی.

168.63.129.16 عامه منزل نه دی

168.63.129.16 د Azure ځانګړې مجازي پلیټفارم پته ده، او یوه دنده یې WireServer ده، چې VM agent یې د فابریک سره د خبرو لپاره کاروي. Microsoft مستند کوي چې د agent ټرافیک TCP پورټ 80 او 32526 ته باید شته وي. دا عادي انټرنیټ کوربه نه دی، او هغه څه نه دی چې بشپړ تونل VPN یې لرې وتلو ته بوځي. له همدې امله روغ ښکاره تونل هم agent وږی ساتلی شي.

د پلیټفارم پتې مستندات هم وايي چې دا پته د کارونکي ټاکل شوو لارو تابع نه ده، چې دا د Azure فابریک ځانګړنه ده نه ستاسو د مېلمه په اړه ژمنه. سیمه ییز فایرول قاعده یا د VPN کلاينټ خپله لارښوونې پالیسي لاهم کولی شي لاره ماته کړي، او هیڅ یو یې د VNet د لارښوونې جدول کې نه ژوند کوي.

که agent د ستونزې راپور ورکوي، مخکې له دې چې هر څه بیا نصب کړئ د خدمت حالت او هغې پتې ته لاره وګورئ.

169.254.169.254 خپل قواعد لري

169.254.169.254 د Azure Instance Metadata Service لپاره link-local پته ده. هغې ته غوښتنې خپلې شرطونه لري: لومړنی NIC او لومړنی IP، د پتې ملاتړ کوونکی DHCP تنظیم، او د هر HTTP proxy څخه تېرېدل. دوی د لرې VPN وتلو یا هر انټرنیټ ګېټوې له لارې لېږل هغه لاسرسی نمونه نه ده چې Microsoft یې بیانوي.

هغه proxy شرط هغو خلکو ته رسېږي چې لاره یې سمه کړې او بیا هم ناکامي ویني. مېلمه HTTP proxy کولی شي IMDS مات کړي پداسې حال کې چې ip route get سم هغه انټرفېس بېرته راوړي چې تاسو تمه لرئ، نو د لارو ترڅنګ proxy استثناوې هم وګورئ.

دا د ډیبګ کولو پر مهال میټاډاټا ځوابونه د ملاتړ ټیکټ کې مه نښلئ. دوی کېدای شي اعتبارنامې او د انسټنس تفصیلات ولري چې له پیښې اوږد ژوند کوي.

د مېلمه پالیسي لارښوونه ولولئ، نه یوازې اصلي جدول

د Linux مېلمه په، درې یوازې-لوستلو کمانډونه طبقې جلا کوي: د پالیسي قواعدو لپاره ip -4 rule show، بیا د هغو پرېکړو لپاره چې کرنل واقعاً کوي ip -4 route get 168.63.129.16 او ip -4 route get 169.254.169.254. دوی د VPN له نښلولو مخکې او وروسته چل کړئ. د دغو دوو تولیداتو توپیر ستاسو د بدلونونو ټولګه ده، او د کلاينټ د کړنو په اړه له هر اټکل څخه ګټور دی.

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

د هغې لارې مخه ونیسئ چې دواړه /32 لارې د زوړ ګېټوې له لارې زیاتوي. link-local پلیټفارم لاره او عمومي WAN بله ټوپ بېل شیان دي، او عمومي استثنا ریښتینی پالیسي ټکر پټوي.

اداره او بیا رغونه جلا وساتئ

ستاسو SSH یا RDP ځواب هم کېدای شي د بشپړ تونل ډیفالټ ونیول شي، خو دا د پلیټفارم پای ټکي پر ځای د مدیر لیدل شوې پتې ته نښه کوي. د هغې د خپلې غوښتنې-ځواب جوړه له مخې تشخیص کړئ، او د VPN پالیسي بدلولو مخکې لکه سیریل کنسول خپلواکه بیا رغونه چینل وساتئ. که ځای پرځای کول VM بیا پیل کړي او agent ناسموالي راپور کړي، د دې پر ځای چې فکر وکړئ لار بدلون بیا پیل کولو لامل شو، ثبت شوې کړنه او مسؤل خدمت وګورئ.

بیا درې جریانونه جلا جلا تایید کړئ: هغه شخصي سرچینه چې واقعاً غواړئ، د agent او پلیټفارم ملاتړ شوی اړیکه، او اداري لاره. د یو بیا رغول دا ثبوت نه دی چې نور دوه ژوندي پاتې شو.

منل شوې استثنا د مېلمه شبکې او VPN تنظیماتو مالک تر نوم لاندې ولیکئ، په دې کې چې د بیا نښلولو او بیا پیل پر مهال څه پېښېږي. Azure UDR د مېلمه لارښوونې جدول نه دی، او د هغوی سمول سیمه ییز پالیسي قاعده نه جوړوي.