IKE میں MAC کا میل نہ کھانا یعنی مشترکہ کلید کی جانچ ناکام ہوئی

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

عملاً یہ دو حالتیں پیدا کرتی ہیں: دونوں سروں کے راز ایک ہی قدر نہیں، یا راز منتخب کرنے کے لیے استعمال ہونے والی شناختیں ایک دوسرے سے مطابقت نہیں رکھتیں۔ کون سی ہے، یہ ایک سرنگ کے بجائے دونوں سرے پڑھ کر طے کریں۔

یہ مرحلہ کیا ثابت کرتا ہے

جانچ اس وقت چلتی ہے جب دونوں فریق ابتدائی پیرامیٹر بدل چکے ہوں اور اپنی شناخت بتا چکے ہوں۔ یہ مقامی اور دور شناختوں کے لیے امیدوار کلیدیں چنتی ہے اور موصول شدہ توثیقی ڈیٹا کی تصدیق کرنے کی کوشش کرتی ہے؛ جب کوئی تصدیق نہ ہو تو تشخیص جاری ہوتی ہے۔ یہ توثیق کے بارے میں مضبوط بیان اور وجہ کے بارے میں کمزور بیان ہے، کیونکہ یہ نہیں بتاتی کہ کون سا فریق غلط ہے۔

پہلی کامیابی اس جانچ میں منتقل نہیں ہوتی۔ مکمل شدہ IKE_SA_INIT، یا NAT کی شناخت کا پے لوڈ جس نے متوقع قدریں واپس کیں، ثابت کرتا ہے کہ ساتھی بات کر سکتے ہیں۔ یہ اس بارے میں کچھ ثابت نہیں کرتا کہ وہ راز مشترک کرتے ہیں یا نہیں۔

دو ترتیبی غلطیاں، ایک پیغام

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

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

NAT کی شناخت ایک الگ مرحلہ ہے

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

ایک وینڈر کے اجرا کے بارے میں پرانا بیان موجودہ تعیناتی میں نہ لے جائیں۔ آپ کے اجرا میں NAT سے گزرنے کے لیے کیا درکار ہے، وہ اسی کی اپنی دستاویز میں ہے، اور MAC کا میل نہ کھانا کے الفاظ اس کے حق یا خلاف ثبوت نہیں۔

اسکرین سے نہیں، دونوں سروں سے فیصلہ کریں

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

اگر تینوں صاف ہوں تو ارد گرد ترمیم کرنے کے بجائے منظور شدہ ورک فلو سے راز بدلیں۔

ساتھی کی توثیق کے بعد

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

دونوں سروں کے تازہ لاگ مربوط کریں ایک ہی جوڑے اور ایک ہی کھڑکی کے لیے۔ ایک فریق دوسرے کے ان پٹ کے بغیر فیصلہ دیتا ہے، اور یہی وہ ابہام ہے جس نے پیغام پہلے پیدا کیا۔

کیا نتیجہ نہ نکالیں

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

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