جب Check Point کی سائٹ سے سائٹ سرنگ اوپر آنا بند کر دے تو دو مختلف تبدیلیاں ایک ہی علامت پیدا کرتی ہیں: پیر کو مختلف بیرونی پتہ نظر آتا ہے، یا وہ اب موصول ہونے والی IKE شناخت مسترد کر دیتا ہے۔ ایک طرف سے لی گئی کیپچر میں دونوں ایک جیسے دکھائی دیتے ہیں۔ یہ طے کرنے کے لیے کہ آپ کو کون سی صورت حال درپیش ہے، تین جانچیں درکار ہیں، اور ان میں سے کوئی بھی لنک کے انتخاب کا پینل نہیں ہے۔

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

دو صورتوں کو الگ کرنے والی تین شرطیں

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

پہلی شرط پوری نہ ہو تو آپ کو روٹنگ یا ترجمے کا مسئلہ ہے۔ دوسری پوری نہ ہو تو پیر کے ساتھ معاہدے کا مسئلہ ہے۔ تیسری نامعلوم ہو تو ترتیب دینا بند کر دیں۔

پہلے بیرونی پیر کا ریکارڈ بنائیں

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

اندرونی محفوظ پری فکسز کو اُس ریکارڈ کے الگ حصے میں رکھیں۔ بیرونی ماخذ بدلنا اور محفوظ LAN پتہ بدلنا دو مختلف کارروائیاں ہیں جو اتفاقاً ایک ہی پالیسی میں رہتی ہیں۔

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

پڑھیں کہ لنک کا انتخاب درحقیقت کیا الگ کرتا ہے

Check Point کی R81.20 میں لنک کے انتخاب کی گائیڈ تین چیزوں کو الگ کرتی ہے جنہیں لوگ ایک میں ملا دیتے ہیں: دور دراز پیر گیٹ وے کے پتے کو کیسے حل کرتا ہے، کون سا روٹ باہر جانے والی ٹریفک لے جاتا ہے، اور کون سا ماخذ IP استعمال ہوتا ہے۔ ہر ایک الگ سوال کا جواب دیتا ہے۔ ان میں سے کوئی بھی وہ شناخت نہیں بدلتا جس کی پیر توثیق کرتا ہے۔

یہی تفریق بتاتی ہے کہ روٹ کی تبدیلی IKE شناخت کو چھوئے بغیر نظر آنے والا بیرونی پتہ کیوں بدل سکتی ہے، اور شناخت کی تبدیلی اُس سرنگ کو کیوں توڑ سکتی ہے جس کی روٹنگ بے داغ ہے۔

RFC 7296 خود IKE کے لیے بھی وہی حد کھینچتا ہے: شناختی پے لوڈ ترسیلی پتہ نہیں ہے۔ مینوفیکچررز اس تفریق کو نافذ کرتے ہیں، از سر نو متعین نہیں کرتے۔

ترتیبات کے پینل سے نہیں، ثبوت سے فیصلہ کریں

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

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

دونوں سروں کو ہم آہنگ کریں اور ریکارڈ رکھیں

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

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

متعلقہ مضامین