دہرائے گئے IKE پیکٹ: گمشدہ منتقلی تلاش کریں

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

خرافات: دہرائی گئی درخواست ایک لنک پر نقصان ثابت کرتی ہے

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

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

دوبارہ بھیجنا دراصل آپ کو کیا بتاتا ہے

IKEv2 میں، دوبارہ بھیجنا اس طرح کام کرتا ہے: جواب نہ آنے پر درخواست کرنے والا درخواست دہراتا ہے، اور جواب دینے والا نیا حساب لگانے کے بجائے اپنا محفوظ جواب دوبارہ بھیج سکتا ہے۔ پیغام کے شناخت کنندگان اسی تبادلے کے ہیں، اور یہی ایک ہی شناخت کنندہ والی دہرائی درخواست کو نئی کوشش کے بجائے پروٹوکول کے کام کے طور پر پہچاننے کے قابل بناتا ہے۔ ابتدائی کوشش کو باہم جوڑنے کے لیے اکثر ماخذ پتے یا آغاز کرنے والے SPI سے زیادہ چاہیے ہوتا ہے، اس لیے پلیٹ فارم کا اپنا تبادلہ ریکارڈ پیکٹ فہرست سے بہتر ہے۔ IKEv1 مختلف شناخت کنندگان کے ساتھ مختلف قواعد اپناتا ہے، اور پہلے پیکٹ کی نقل کے بارے میں فروش کی وارننگ تمام ورژنوں میں ایک جیسا مطلب نہیں رکھتی۔

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

عملی نتیجہ یہ ہے کہ نتیجہ اخذ کرنے سے پہلے تبادلہ ریکارڈ کریں۔ مقامی وصولی کا پتہ، پالیسی کا منتخب کردہ جوابی راستہ، پیر ٹپل اور تبادلے کے شناخت کنندگان ایک ہی جگہ لکھیں، کیونکہ ریکارڈ بعد میں پڑھے جانے پر ان میں سے ہر ایک الگ سوال کا جواب دیتا ہے۔

ایک ہی زنجیر کے طور پر چار مشاہداتی نکات

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

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

پہلی گمشدہ منتقلی تلاش کریں

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

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

tcpdump -ni any -vv 'udp port 500 or udp port 4500'

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

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

مفید رپورٹ کیا کہتی ہے

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

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

خرافات یہ ہے کہ ایک نقل آپریٹر کا قصور ثابت کرتی ہے۔ حقیقت یہ ہے کہ ایک نقل ٹائمر کے ختم ہونے کا ثبوت ہے، اور جواب جوابی راستے ہی پر رہتا ہے۔