کام کرنے والے IPsec گیٹ وے سے ike-scan کو کوئی جواب نہیں ملتا

گیٹ وے ہر روز فونز اور لیپ ٹاپس کی خدمت کرتا ہے، پھر بھی ike-scan بتاتا ہے کہ کسی میزبان نے جواب نہیں دیا۔ یہ آؤٹ پٹ آلے میں IPsec نہ ہونے کے ثبوت کی طرح پڑھا جاتا ہے۔ عام طور پر اس کا مطلب یہ ہے کہ آلے نے پروب میں ہر تجویز کو رد کر دیا اور کچھ بھی جواب نہ دینے کا انتخاب کیا۔ خاموشی بھی ایک جواب ہے، اور یہ وہ سب سے کم معلوماتی جواب ہے جو یہ آلہ آپ کو دے سکتا ہے۔

تین الگ سوالات پر غور کریں: پیکٹ پہنچا، کوئی تجویز ملی، اور کسی اور چیز نے ساتھی کو مسترد کیا؟

مرحلہ 1: آلہ جو تجویز بھیجتا ہے اسے پڑھیں

بنیادی موڈ SA پے لوڈ سے شروع ہوتا ہے جو ان ٹرانسفارمز کی فہرست دیتا ہے جو آغاز کرنے والا قبول کرے گا، اور ike-scan اس فہرست کو کمپائل شدہ ڈیفالٹ سے بھرتا ہے۔ ڈیفالٹ سیٹ جان بوجھ کر پرانا ہے: انکرپشن کے لیے DES اور 3DES، ہیشنگ کے لیے MD5 اور SHA1، کلید کے تبادلے کے لیے گروپ 1 اور 2، تصدیق کے لیے پہلے سے مشترکہ کلیدیں۔ کوئی AES نہیں، کوئی SHA-2 نہیں، کوئی گروپ 14 نہیں۔ AES-256، SHA-256 اور modp2048 کے لیے ترتیب دیا گیا گیٹ وے اس کے ساتھ کچھ بھی مشترک نہیں رکھتا۔

کچھ نفاذ غیر مطابق پروب کا جواب NO-PROPOSAL-CHOSEN اطلاع سے دیتے ہیں۔ دیگر اسے صرف پھینک دیتے ہیں، جو ایسے آلات میں عام ہے جو نامعلوم ساتھیوں کو شور سمجھتے ہیں۔ کسی بھی طرح اسکین کچھ نہیں چھاپتا، اور وہ «کچھ نہیں» باہر سے دکھنے والے فلٹر شدہ UDP 500 جیسا ہی ہوتا ہے، جیسا کہ ike-scan منصوبے کی دستاویز ڈیفالٹ سیٹ کے بارے میں واضح کرتی ہے۔

مرحلہ 2: ایک جدید تجویز دیں

ڈیفالٹ سیٹ کو --trans سے بدلیں۔ صفت کی شکل IKE صفت نمبر براہ راست لیتی ہے: انکرپشن کے لیے 1، ہیش کے لیے 2، تصدیق کے لیے 3، گروپ کے لیے 4 اور 14 کلید کی لمبائی کے لیے جب الگورتھم ایک لیتا ہے۔ جو باہر آتا ہے وہ ایک سطر ہے جسے آپ تبدیلی کے جائزے میں بلند آواز سے پڑھ سکتے ہیں۔

پوزیشنل شکل وہی اقدار ترتیب سے لے کر جاتی ہے اور بریکٹ سے بچتی ہے، جو اہم ہے جب کمانڈ شیل سے گزرتی ہے۔

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

ہر پیکٹ پر ایک تجویز گنتی کے وقت سست ہوتی ہے، اس لیے ممکنہ اقدار پر لوپ کریں: انکرپشن 5، 7/128، 7/192، 7/256؛ ہیش 1، 2، 5، 6، 7؛ گروپ 1، 2، 5، 14، 15، 19، 20، 21؛ تصدیق پہلے سے مشترکہ کلید کے لیے 1 اور RSA دستخطوں کے لیے 3۔ ہر کمانڈ چلانے سے پہلے چھاپیں تاکہ ریکارڈ دکھائے کہ کیا پیش کیا گیا اور کس ترتیب میں۔

مرحلہ 3: جواب کی تشریح کریں

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

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

مرحلہ 4: خاموشی کی تشریح کریں

خاموشی دکھنے سے کمزور ثبوت ہے۔ ہر تجویز مسترد ہو سکتی ہے، UDP 500 اور 4500 فلٹر ہو سکتے ہیں، ماخذ بھڑکاؤ کے بعد رفتار میں محدود ہو سکتا ہے، یا سروس آپ کے اسکین کردہ پتے کے علاوہ کسی اور پتے پر سن رہی ہو سکتی ہے۔ باکس کے بارے میں کوئی نتیجہ نکالنے سے پہلے گیٹ وے کے IKE لاگ کا موازنہ ایسے کلائنٹ سے کریں جو پہلے ہی درست اسناد کے ساتھ جڑا ہوا ہو۔

بھڑکاؤ کا رویہ اس فہرست میں شامل ہے کیوں کہ گنتی مختصر وقفے میں بہت سے پیکٹ پیدا کرتی ہے۔ پہلی کوششوں کا جواب دے کر پھر خاموش ہو جانے والا گیٹ وے اپنی تجاویز کا سیٹ نہیں، اپنی anti-DoS پالیسی بیان کر رہا ہوتا ہے۔

مرحلہ 5: جو آپ نے ثابت کیا اسے لکھیں

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

جس پروب نے کبھی جواب نہیں دیا اس نے بھی کسی چیز کا جواب دیا: یہ دکھاتا ہے کہ یہ آلہ کون سی تجاویز پر بحث کرنے کو تیار ہے اور کون سی فرش پر گرانا پسند کرے گا۔