PPP پر مبنی VPN سے اس کے مفروضوں کی نقل کیے بغیر منتقلی

VPN کی منتقلی اُس وقت مکمل ہوتی ہے جب صارفین، منزلیں، ناموں کا حل اور ناکامی کے وقت رویہ سب اب بھی درست ہوں، نہ کہ جب نیا کلائنٹ سبز نشان دکھائے۔ پرانی PPP پر مبنی تنصیبات ایسے مفروضے اٹھائے پھرتی ہیں جو کبھی تحریر نہیں کیے گئے: ایک مشترکہ راز جو واحد شناخت جانچ بھی تھا، ایک مقررہ پتہ پول جسے فائر وال اجازت یافتہ فہرست میں رکھتا ہے، اور ایک DNS لاحقہ جو سرور بھیجتا ہے۔ ان مفروضوں کی فہرست بنائے بغیر پروٹوکول بدلنے سے ایسی سرنگ ملتی ہے جو ہینڈ شیک مکمل کرتی ہے اور ایسی حد جو موجود ہی نہیں۔ نیچے دیا گیا ترتیب وہی ہے جو میں استعمال کرتا ہوں، اور آخری مرحلہ وہی ہے جسے ٹیمیں چھوڑ دیتی ہیں۔

مرحلہ 1: فہرست بنائیں کہ پرانا کنکشن کیا دیتا ہے

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

L2TP/IPsec کے لیے دونوں تہیں واضح طور پر الگ کریں۔ IPsec ساتھی کی شناخت مشینوں کی تصدیق کرتی ہے؛ PPP صارف کی تصدیق کرتا ہے، عام طور پر CHAP یا MSCHAPv2 سے۔

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

مرحلہ 2: متبادل کو دانستہ ڈیزائن کریں

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

سب سے پہلے پتہ کی حدیں ہم آہنگ کریں، کیونکہ گھر یا دفتر کے LAN سے متجاوز متبادل پول ایسی ناکامی پیدا کرتا ہے جس کا سائفر کی طاقت سے کوئی تعلق نہیں۔ پول کو اسی فہرست کے سامنے جانچیں جو آپ نے پرانی سروس کے لیے بنائی تھی، نیز اُس کے سامنے جو نیا کلائنٹ طے شدہ طور پر فرض کرتا ہے۔ محفوظ نیٹ ورکوں کے لیے واپسی روٹنگ کی تصدیق کریں، اور تصدیق کریں کہ نیا کلائنٹ وہ DNS لاحقہ بھیج یا درج کر سکتا ہے جو پرانا بھیجتا تھا۔ یہی دو امور پروٹوکول کی تبدیلی سے زیادہ منتقلی ٹکٹ بناتے ہیں۔

مرحلہ 3: مرحلہ وار نافذ کریں اور اجازت و انکار دونوں کی تصدیق کریں

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

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

منتظم کی رسائی منتقل کرنے سے پہلے تصدیق کریں کہ آپ کے پاس مجاز بحالی راستہ ہے جو اُس سرنگ پر منحصر نہیں جسے آپ بدل رہے ہیں۔

مرحلہ 4: پرانی شناخت کو ریٹائر کریں

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

اُس موڑ پر سست ہونا مناسب ہے۔ لیپ ٹاپ پر ریٹائر شدہ کلائنٹ پروفائل منسوخ شدہ سند نہیں؛ سند سرور پر رہتی ہے اور سرور کے قبول کرنا چھوڑنے تک درست رہتی ہے۔ پرانی ترتیب کی دیگر نقول تلاش کریں — آزمائشی آلات، بھولا ہوا فون، کسی کا رکھا ہوا انسٹالر — اور سامع کو بند کرنے کو وہ لمحہ سمجھیں جب پرانی سروس واقعی ختم ہوتی ہے۔ تب تک منتقلی کے دو سامنے کے دروازے ہیں۔

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

نتیجے کو پروٹوکول کے نام کے بجائے سروس کی ضرورت سے باندھ کر رکھیں، کیونکہ پرانے مفروضے نقل کیے گئے جدید پروٹوکول بہتر فریم کے ساتھ وہی خطرہ ہیں۔ RFC 3193 بیان کرتا ہے کہ L2TP کس طرح IPsec پر ڈھویا جاتا ہے، جو یہ مفید یاد دہانی ہے کہ دونوں تہیں ہمیشہ الگ فیصلے تھیں۔ اگر فہرست میں کوئی قطار ایسی ہو جسے آپ سمجھا نہیں سکتے تو رکیں اور معلوم کریں کہ اُس پر کیا منحصر ہے۔ فہرست بور ہو جانے پر منتقلی مکمل ہوتی ہے۔