VPN شروع ہونے کے بعد Azure VM IMDS یا WireServer تک نہیں پہنچتا

VM چل رہا ہے، VPN کلائنٹ کہتا ہے کہ منسلک ہے، اور چند منٹ بعد Azure ایجنٹ غیر صحت مند حالت کی رپورٹ دینے لگتا ہے۔ کبھی SSH بچا رہتا ہے اور پورٹل کا Run Command نہیں، جو لوگوں کو راؤٹ ٹیبل کی بجائے ایجنٹ کی طرف دیکھنے پر مجبور کرتا ہے۔ ٹنل بلند ہونے پر مہمان کے اپنے فارورڈنگ فیصلے بدل گئے، اور عام طور پر دو پلیٹ فارم پتے پہلے شکار ہوتے ہیں۔ میں اسے ایجنٹ کی ناکامی سمجھنے سے پہلے راؤٹنگ کی علامت سمجھتا ہوں۔

علامت خراب ایجنٹ جیسی لگتی ہے

نیچے دیے گئے دونوں پتے حل کے طور پر تجویز کیے جاتے ہیں، حالانکہ وہ ایک ہی سروس نہیں ہیں۔ ایک کے لیے /32 کاپی کرنا کیونکہ وہ دوسرے کے لیے کام آیا تھا—اسی طرح عارضی حل وہ مستقل ترتیب بن جاتا ہے جسے ہٹانے کی کسی کی ہمت نہیں ہوتی۔

کام کرنے والا ترتیب یہ ہے: پہلے تصدیق کریں کہ ناکام کال واقعی کس پتے کو نشانہ بناتی ہے، پھر پڑھیں کہ مہمان اسے کیسے حل کرتا ہے۔ باقی سب اضافی مراحل کے ساتھ اندازہ اور طویل تبدیلی کی ونڈو ہے۔

168.63.129.16 عوامی منزل نہیں ہے

168.63.129.16 Azure کا خصوصی مجازی پلیٹ فارم پتہ ہے، اور اس کا ایک کردار WireServer ہے، جسے VM ایجنٹ فیبرک سے بات کرنے کے لیے استعمال کرتا ہے۔ Microsoft دستاویز کرتا ہے کہ ایجنٹ کی TCP پورٹ 80 اور 32526 تک ٹریفک دستیاب رہنی چاہیے۔ یہ عام انٹرنیٹ ہوسٹ نہیں ہے، اور یہ ایسی چیز نہیں جسے مکمل ٹنل VPN کو دور دراز ایگزٹ تک لے جانا چاہیے۔ اسی لیے صحت مند نظر آنے والا ٹنل بھی ایجنٹ کو بھوکا رکھ سکتا ہے۔

پلیٹ فارم پتے کی دستاویز یہ بھی کہتی ہے کہ یہ پتہ صارف کی متعین کردہ راہوں کے تابع نہیں، جو Azure فیبرک کی خصوصیت ہے، آپ کے مہمان کے بارے میں وعدہ نہیں۔ مقامی فائر وال قاعدہ یا VPN کلائنٹ کی اپنی راؤٹنگ پالیسی پھر بھی راستہ توڑ سکتی ہے، اور ان میں سے کوئی بھی VNet کے راؤٹ ٹیبل میں نہیں رہتا۔

اگر ایجنٹ ہی مسئلے کی رپورٹ کر رہا ہے، تو کچھ بھی دوبارہ انسٹال کرنے سے پہلے سروس کی حالت اور اس پتے تک کا راستہ جانچیں۔

169.254.169.254 کے اپنے قواعد ہیں

169.254.169.254 Azure Instance Metadata Service کا link-local پتہ ہے۔ اس کی طرف درخواستوں کی اپنی شرطیں ہیں: بنیادی NIC اور بنیادی IP، پتے کو سپورٹ کرنے والی DHCP ترتیب، اور کسی بھی HTTP پروکسی کو بائی پاس کرنا۔ انہیں دور دراز VPN ایگزٹ یا من مانی انٹرنیٹ گیٹ وے سے بھیجنا وہ رسائی ماڈل نہیں جو Microsoft بیان کرتا ہے۔

یہ پروکسی شق ان لوگوں کو پکڑتی ہے جنہوں نے راستہ درست کیا اور پھر بھی ناکامیاں دیکھتے ہیں۔ مہمان کا HTTP پروکسی IMDS کو توڑ سکتا ہے جبکہ ip route get بالکل وہی انٹرفیس واپس کرتا ہے جس کی آپ توقع کرتے ہیں، لہٰذا راستوں کے ساتھ پروکسی استثنائیں بھی دیکھیں۔

اسے ڈیبگ کرتے وقت میٹاڈیٹا جوابات سپورٹ ٹکٹ میں نہ چسپاں کریں۔ ان میں ایسی اسناد اور انسٹانس تفصیلات ہو سکتی ہیں جو واقعے سے زیادہ عرصہ رہیں۔

مہمان کی پالیسی راؤٹنگ پڑھیں، صرف مرکزی ٹیبل نہیں

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 دوبارہ شروع کرے اور ایجنٹ غیر صحت مندی بتائے، تو یہ ماننے کی بجائے کہ راستے کی تبدیلی نے ری بوٹ کیا، درج شدہ کارروائی اور ذمہ دار سروس جانچیں۔

پھر تینوں بہاؤ الگ الگ جانچیں: وہ نجی وسیلہ جو آپ واقعی چاہتے تھے، معاون ایجنٹ اور پلیٹ فارم رابطہ، اور انتظامی راستہ۔ ایک کی بحالی اس بات کا ثبوت نہیں کہ باقی دو بچ گئے۔

منظور شدہ استثنا مہمان نیٹ ورک اور VPN ترتیب کے مالک کے نام لکھیں، بشمول دوبارہ منسلک ہونے اور دوبارہ شروع ہونے پر کیا ہوتا ہے۔ Azure UDR مہمان کا راؤٹ ٹیبل نہیں ہیں، اور انہیں تبدیل کرنا مقامی پالیسی قاعدہ درست نہیں کرے گا۔