Azure VM پر RRAS معاون نہیں: ڈیزائن سے پہلے جانچیں

آپ پورٹل کھولتے ہیں، Windows Server 2022 کو سب نیٹ میں تعینات کرتے ہیں، اور Remote Access کردار صاف ستھرا نصب ہوتا ہے۔ یہ ترتیب ثابت کرتی ہے کہ انسٹالر کام کرتا ہے، یہ نہیں کہ Microsoft اس ترتیب کی معاونت کرتا ہے۔ Azure مجازی مشینوں کے لیے شائع شدہ سرور سافٹ ویئر معاونت کی رہنمائی RRAS کو ان Windows Server خصوصیات میں شمار کرتی ہے جو Azure VM پر معاون نہیں، اور یہ فن تعمیر کا فیصلہ ہے، مسائل حل کرنے کی تفصیل نہیں۔ جو سرنگ اوپر آتی ہے وہ تعیناتی کو معاونت کی حد کے اندر نہیں لاتی۔

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

لیبارٹری میں نہیں، معاونت کے صفحے سے شروع کریں

کچھ بھی ناپنے سے پہلے Azure VM معاونت کی رہنمائی پڑھیں۔ یہ Windows Server کو ایک غیر متنوع بلاک سمجھنے کے بجائے معاون مصنوعات، کرداروں اور خصوصیات کو الگ کرتی ہے۔ غور کریں کہ آپ کا مطلوبہ کام کا بوجھ اصل میں کس قطار میں آتا ہے، کیونکہ کنسول میں متعلق دکھنے والے دو اجزا مختلف قطاروں میں ہو سکتے ہیں۔

صفحہ کھلا ہونے کے دوران ہی ڈیزائن دستاویز میں حوالہ لکھیں۔ معاونت کی حیثیت ماخذ والی حقیقت ہے، اور جو ڈیزائن جائزہ اس کا حوالہ نہیں دے سکتا اسے ڈیمو رکھنے والا شخص بحث میں ہرا دے گا۔

OS کی معاونت کو کردار اور خصوصیت کی معاونت سے الگ رکھیں

وہی رہنمائی Network Policy and Access Services کو معاون کرداروں میں رکھتی ہے جبکہ RRAS کو الگ سے غیر معاون بتاتی ہے۔ یہ دو اندراجات مختلف چیزیں بیان کرتے ہیں، اور انہیں “ریموٹ رسائی معاون ہے” میں یکجا کرنا ہی غلط پڑھنے کی بنیاد پر منصوبے کی منظوری کا راستہ ہے۔ آپریٹنگ سسٹم کا معاون ہونا اپنی قطار والی خصوصیت کے بارے میں کچھ نہیں کہتا۔

یہ حد بعض اوقات جتنا حوالہ دیا جاتا ہے اس سے بھی تنگ ہے۔ یہ Azure VM کے اندر چلنے والی اسی خصوصیت سے متعلق ہے؛ اس کا مطلب یہ نہیں کہ نجی نیٹ ورک Azure سے جڑ نہیں سکتا، اور یہ بھی نہیں کہتا کہ RRAS ہر جگہ غیر معاون ہے۔ پرانی لیبارٹری جو پیکٹ صحیح طور پر آگے بھیجتی ہے، پیکٹوں کے بارے میں ثبوت ہے، معاونت کے بیان کے بارے میں نہیں۔

باقی منصوبے کے دوران ان دو سوالوں کو الگ رکھیں: کیا یہ کام کرتا ہے، اور کیا یہ معاون ہے۔ آپ کو ہر ایک کے لیے مختلف جوابات اور بعض اوقات مختلف ذمہ دار افراد درکار ہوں گے۔

لکھیں کہ ڈیزائن کو اصل میں کیا کرنا ہے

متبادل چننے سے پہلے سائٹوں کی فہرست کو ایسے تقاضوں میں بدلیں جن پر مصنوعات کو ناپا جا سکے:

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

NAT وہ شے ہے جسے چھوڑ دیا جاتا ہے اور پھر پورا ڈیزائن طے کرتا ہے۔ جو آلہ IPsec قائم کر سکتا ہے وہ اب بھی ان پتوں کا ترجمہ اس RRAS تعیناتی سے مختلف طریقے سے کر سکتا ہے جس کی وہ جگہ لے رہا ہے، اور اس سے بدلتا ہے کہ شاخ کن پتوں کو ماخذ کے طور پر دیکھتی ہے اور آپ کے لاگ کیا ریکارڈ کرتے ہیں۔

فہرست نیٹ ورک مالکان کے پاس لے جائیں اور کسی بھی مصنوعات کی گفتگو سے پہلے اس کی تصدیق کریں۔ مبہم تقاضے ہر فروش کے موازنے کو ترجیح کی بحث میں بدل دیتے ہیں۔

انہی تقاضوں کے خلاف متبادلوں کا جائزہ لیں

Azure کی زیر انتظام رابطہ خدمات اور فروش کی معاونت یافتہ نیٹ ورک مجازی آلات، دونوں کو ایک ہی فہرست کے خلاف نمبر دیے جانے چاہئیں۔ یہ نہ سمجھیں کہ ان میں سے کوئی RRAS VM کا براہ راست متبادل ہے صرف اس لیے کہ یہ IPsec ختم کر سکتا ہے: NAT ماڈل اور راستوں کی ملکیت اور اعلیٰ دستیابی کا ڈیزائن طے کرتے ہیں کہ موجودہ سائٹیں کیسے جڑتی ہیں اور ان کے جواب کہاں واپس آتے ہیں۔ ہر امیدوار کو کاغذ پر فہرست کے خلاف نمبر دیں اور لکھیں کہ کون سے تقاضے پورے نہیں کرتا، کیونکہ وہی نوٹ انتخاب کو بعد میں قابل جائزہ بناتا ہے۔

دو آلات VM کے سامنے لوڈ بیلنسر بذات خود اعلیٰ دستیابی نہیں۔ یہ سامنے کا حصہ دیتا ہے، ہم آہنگ سرنگ کی حالت نہیں، اور ہر سیشن گرا دینے والی ناکامی کی منتقلی ایسا ڈیزائن فیصلہ ہے جو کسی کو جان بوجھ کر لینا ہوگا۔ آلات فروش سے پوچھیں کہ معاون HA نمونہ کیا ہے اور کیا وہ سائٹوں سے وعدہ کی گئی دستیابی سے میل کھاتا ہے۔ ان سائٹوں کے اس پر انحصار سے پہلے ناکامی کی منتقلی آزمائیں، اور ہر گمشدہ سیشن کو حیرت نہیں بلکہ دریافت سمجھیں۔

جہاں تقاضا واقعی سادہ ہے — ایک سائٹ، ایک سابقہ، کوئی تداخل نہیں — وہاں زیر انتظام خدمت عام طور پر آپریشنل لاگت میں جیتتی ہے۔ جہاں ترجمہ اور متحرک روٹنگ دونوں کھیل میں ہیں، وہاں آلے کا راستہ واحد موزوں ہو سکتا ہے، اور یہ غیر معاون VM رکھنے کے بجائے طویل منتقلی کی منصوبہ بندی کرنے کی وجہ ہے۔

اگر RRAS VM پہلے سے چل رہا ہے

دریافت اسے حذف کرنے کی وجہ نہیں۔ تبدیلی کی منصوبہ بندی ان انحصاروں کے گرد کریں جو اس VM نے جمع کیے: وہ راستے جن پر دوسرے سب نیٹ بھروسہ کرتے ہیں، ماخذ پتے چھپانے والے NAT قواعد، اور وہ سب کچھ جو نگرانی نے اس کے پتے سے توقع کرنا سیکھا ہے۔ ضروری راستے اور آزمودہ بحالی کا راستہ محفوظ رکھیں جبکہ معاون ہدف ساتھ ساتھ ڈیزائن اور تصدیق ہو رہا ہو۔

معاونیت اور تکنیکی تشخیص کو ہر وقت الگ نتائج کے طور پر رکھیں۔ غیر معاون ترتیب میں عام روٹنگ کی خرابی بھی ہو سکتی ہے، اور اس خرابی کو درست کرنے سے اس کی معاونت کی حیثیت نہیں بدلتی۔ دونوں بیانات رپورٹ میں ہیں، اور کوئی ایک دوسرے کو منسوخ نہیں کرتا۔

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