پیکٹ کیپچر میں پہلا IKEv2 تبادلہ کیسے پڑھیں

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

تصدیق کریں کہ آپ ابتدائی تبادلہ دیکھ رہے ہیں

IKEv2 گفت و شنید IKE_SA_INIT سے شروع ہوتی ہے، تبادلے کی قسم 34، پیغام آئی ڈی 0۔ شروع کرنے والا غیر صفر SPI چنتا ہے، اور جواب دینے والے کا SPI اسی پہلی درخواست میں صفر اور جواب میں غیر صفر ہوتا ہے۔ یہ تین حقائق نئی کوشش کو چابی کی تجدید یا کیپچر کے اوپر اتفاقاً موجود IKE_AUTH پیغام سے الگ کرتے ہیں۔

ہیڈر کے فیلڈ پڑھنے کے قابل ہیں، اور تجویز، چابی کے تبادلے اور nonce کے پے لوڈ بھی۔ پڑھنے کے قابل ہونا تصدیق شدہ ہونا نہیں: اس موقع پر کسی فریق نے شناخت ثابت نہیں کی، اور Diffie-Hellman کی نجی قیمت کبھی تار پر ظاہر نہیں ہوتی۔

ڈیکوڈ پینل میں اسکرول کرنے کے بجائے فیلڈ کو جدول کے طور پر چھاپیں، کیونکہ دوبارہ بھیجنا اور نہ ملنے والے SPI کالم میں واضح ہو جاتے ہیں۔

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

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

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

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

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

خفیہ شدہ شناخت اور تصدیقی پے لوڈ صرف IKE_AUTH، یعنی دوسرا تبادلہ، لے کر جاتا ہے۔ اس لیے مکمل شدہ IKE_SA_INIT آپ کو بتاتا ہے کہ فریق الگورتھم اور ماخوذ چابیوں پر متفق ہیں، اور اس بارے میں کچھ بھی نہیں کہ اسناد قبول ہوں گی یا نہیں۔ وہاں بھی دو پیغامات کی توقع رکھیں، اور توقع رکھیں کہ سیشن چابیوں کے بغیر دونوں مبہم رہیں گے۔

پورٹ 4500 ایک پروٹوکول نہیں ہے

عام طور پر UDP 500 ابتدائی تبادلہ لے کر جاتا ہے۔ NAT کی شناخت چلنے کے بعد IKE 4500 پر منتقل ہو جاتا ہے اور ہر پیغام سے پہلے چار بائٹ کا صفر غیر ESP نشان لگاتا ہے۔ اسی پورٹ پر encapsulated ESP اس کے برعکس غیر صفر ESP SPI سے شروع ہوتا ہے، اور ایک بائٹ کا NAT keepalive تیسری شکل ہے جو اس وقت ظاہر ہوتی ہے جب اور کچھ نہ ہو رہا ہو۔

صرف پورٹ سے ملنے والا فلٹر تینوں کو ملا دیتا ہے، اسی لیے "4500 پر ٹریفک ہے" بہت کم طے کرتا ہے۔ دور کے سرے کے بارے میں کوئی نتیجہ نکالنے سے پہلے منظر کو پروٹوکول کے مطابق تقسیم کریں۔

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

خاموشی مشاہدے کے نقطے کو بیان کرتی ہے

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

ICMP ناقابل رسائی ہونا ایک اور قسم کا ثبوت ہے۔ اس کے اندر نقل شدہ پیکٹ پڑھیں اور پہچانیں کہ کس آلے نے اسے خارج کیا، کیونکہ راؤٹر کا انتظامی انکار دور کے سرے سے تصدیق شدہ خرابی نہیں ہے۔

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

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