L2TP پروفائل کی کون سی پرت واقعی ٹوٹی

ترتیبات کے صفحے پر آڑے نہ جائیں، اسٹیک میں نیچے جائیں: IPsec گفت و شنید، پھر L2TP کنٹرول، پھر PPP توثیق، پھر پتہ اور DNS تفویض۔ ہر پرت کا اپنا نقصِ دستخط اور اپنی ممکنہ وجہ ہے۔ صارف کی توثیق میں ناکام ہونے والا پروفائل پہلے ہی تین جانچوں سے گزر چکا ہے جہاں پہلے وقت ختم ہونے والا پروفائل کبھی نہیں پہنچا۔ یہی ترتیب پہلے طے کرنی ہے۔

پروٹوکول کا ایک ہی نام چار مختلف گفتگوؤں کو چھپاتا ہے۔

ترتیبات بدلنے سے پہلے پرت کا نام رکھیں

IPsec سیٹ اپ کی ناکامی مشترکہ راز، الگورتھم یا سامنے والے فریق کی شناخت کی طرف اشارہ کرتی ہے۔ اس کے بعد L2TP کنٹرول ناکام ہو تو یہ خود سرنگ کی پرت کی نشاندہی ہے، جو زیادہ تنگ مسئلہ ہے۔ PPP توثیق کی ناکامیاں اکاؤنٹ یا توثیق کے طریقے کا نام لیتی ہیں۔ توثیق کے بعد پتہ یا DNS کی ناکامی کا مطلب ہے کہ ترسیل کام کر گئی اور ترتیب کا تبادلہ نہیں۔

کلائنٹ کا ورژن، آپریٹنگ سسٹم کا ورژن اور آپریٹر کی دستاویزی ترتیب لکھ لیں۔ ان تینوں کے بغیر ہر تبدیلی ایک اندازہ ہے جو اتفاقاً کچھ اور ٹھیک کر سکتا ہے۔

پروفائل کا موجودہ کلائنٹ سے موازنہ کریں

محفوظ پروفائل میں ایسا مشترکہ راز، توثیق کا اختیار یا اختتامی نقطہ ہو سکتا ہے جسے موجودہ کلائنٹ اب قبول نہیں کرتا۔ کچھ پلیٹ فارمز نے L2TP/IPsec کی معاونت مکمل طور پر واپس لے لی یا ہٹا دی ہے، اور اپ ڈیٹ شدہ کلائنٹ سرور پر کسی تبدیلی کے بغیر پرانا IKE رویہ چھوڑ سکتا ہے۔ اپنے محفوظ کیے گئے اقدار کا موازنہ آپریٹر کی موجودہ دستاویزی ضروریات سے کریں، ایک سال پہلے کیا کام کرتا تھا اس سے نہیں۔ ان دو دستاویزات کے درمیان فرق ہی عام طور پر وہ جگہ ہے جہاں جواب ہوتا ہے۔

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

پرانے اختیارات فعال کرنے سے واپس نہیں آتے

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

سب کچھ فعال کرنے والی مرمت اصل خرابی سے کہیں زیادہ بدلتی ہے اور آپ کو یہ بتانے سے قاصر چھوڑ دیتی ہے کہ اسے کس نے ٹھیک کیا۔

منتقلی کو منصوبے کے طور پر پیش کریں

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

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

پرت، کلائنٹ کا ورژن اور آپریٹر کی موجودہ ضروریات جانچیں۔ پھر فیصلہ کریں کہ یہ مرمت ہے یا متبادل۔