IPsec گیٹ وے کے لیے WireGuard پروفائل: اس کے بجائے کیا پوچھیں

خاموش گیٹ وے کے ساتھ ہینڈ شیک کا وقت ختم ہونا عام طور پر دو پروٹوکول کا مطلب ہوتا ہے جو کبھی نہیں ملتے۔ WireGuard پیر Noise بولتا ہے جبکہ IPsec گیٹ وے IKE کا انتظار کرتا ہے۔ درست پتہ اور پورٹ اسے نہیں بدلتے۔

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

پہلی درخواست: پروٹوکول ورژن

IPsec ایک خاندان کا نام دیتا ہے، کوئی واحد کام کا بہاؤ نہیں۔ IKEv2 اور IKEv1 اپنے تبادلوں، تصدیق کے اختیارات اور نیٹ ورک بدلنے پر رویے میں مختلف ہیں۔ صرف IKEv1 ختم کرنے والا گیٹ وے IKEv2 پیش کرنے والے گیٹ وے سے بالکل مختلف برتاؤ کرے گا۔ کلائنٹ کی ترتیب بھی اس کے ساتھ بدلتی ہے۔

پوچھیں کہ سروس کون سا ورژن ختم کرتی ہے اور کیا یہ معیار پر مبنی عمل درآمد چلاتی ہے یا اپنے کلائنٹ والا وینڈر کا روپ۔ آپریٹنگ سسٹم کے مینو اکثر اس جواب کو ایک لیبل کے پیچھے چھپا دیتے ہیں۔ لیبل ہی پروٹوکول نہیں ہے۔

دوسری درخواست: کلائنٹ کی تصدیق کا طریقہ

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

WireGuard کی نجی کلید ان میں سے کچھ بھی نہیں ہے۔ یہ ایک مخصوص ہینڈ شیک میں استعمال ہونے والی Curve25519 کلید ہے۔ کوئی تبدیلی اسے سرٹیفکیٹ یا EAP اسناد نہیں بناتی۔ جو آلہ اس کے برعکس دعوی کرتا ہے وہ فائل کا نام بدل رہا ہے یا غیر متعلق کچھ بنا رہا ہے۔

RFC 7296 میں IKEv2 تصریح بیان کرتی ہے کہ اس ورژن کے عمل درآمد کو کس چیز کی حمایت کرنی چاہیے۔ یہ آپریٹر کے مبہم جواب کے لیے حوالہ ہے، کلائنٹ ترتیب کی رہنمائی نہیں۔

تیسری درخواست: قابلِ اعتماد شناخت اور منزلیں

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

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

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

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

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

جب دونوں پروٹوکول کو ساتھ رہنا ہو

دونوں نیٹ ورک کا انتظام دونوں پروٹوکول رکھنے کی جائز وجہ ہے۔ عام ڈیزائن WireGuard اور IPsec کو الگ انٹرفیس یا الگ گیٹ وے پر ختم کرتا ہے۔ منظور شدہ ٹریفک پھر ان کے درمیان روٹ کیا جاتا ہے۔

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

یہ جو نہیں ہے وہ شفاف تبدیلی ہے۔ WireGuard کے ذریعے آنے والا ٹریفک IPsec سرنگ میں دوبارہ پیدا ہوتا ہے، اور درمیان کی ہر پالیسی اس پر لاگو ہوتی ہے۔

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