strongSwan ESP-in-UDP: جب تلاش کرنے کے لیے کوئی NAT نہ ہو

NAT کی نشاندہی ایک سوال کا جواب دیتی ہے: کیا راستے میں پتے یا پورٹ بدلے؟ یہ نہیں بتاتی کہ کوئی فائر وال IP پروٹوکول 50 کی اجازت دیتا ہے یا نہیں۔ بغیر کسی ترجمے والے سائٹ گیٹ وے اب بھی ایسی پالیسی کے پیچھے ہو سکتے ہیں جو native ESP گرا دیتی ہے، اور وہ ضرورت تلاش کرنے کے بجائے ترتیب دی جانی چاہیے۔ طریقہ کار ESP-in-UDP ہے، اور یہ فیصلہ ہے، خود بخود آنے والا متبادل نہیں۔

نشاندہی پتوں پر حساب ہے، فائر وال کی جانچ نہیں

IKEv2 NAT نشاندہی کے پے لوڈ لے کر چلتا ہے جن میں ماخذ اور منزل کے پتوں اور پورٹوں کے ہیش ہوتے ہیں۔ ہر فریق جو ملا اس کا موازنہ مقامی طور پر نظر آنے والے سے کرتا ہے، اور فرق ہونے پر اسے پتہ چلتا ہے کہ کسی چیز نے پیکٹ کا ترجمہ کیا۔ اس تبادلے میں کچھ بھی یہ نہیں جانچتا کہ درمیان کا راؤٹر پروٹوکول 50 آگے بھیجتا ہے یا نہیں۔

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

اس لیے انکیپسولیشن آپ کے ترتیب کردہ کنکشن کی خصوصیت ہے، نیٹ ورک کے رویے سے فریقین کے طے کردہ نتیجے کی نہیں۔

encap تبادلے کو کیسے بدلتا ہے

جدید strongSwan تعیناتی میں، جو swanctl.conf کے ذریعے منظم ہوتی ہے، کنکشن پر encap = yes ترتیب NAT نشاندہی کے تبادلے پر اثر ڈالتی ہے تاکہ دونوں فریق ESP کے لیے UDP انکیپسولیشن استعمال کریں۔ محفوظ پیکٹ پھر UDP کے اندر، عام طور پر پورٹ 4500 پر سفر کرتے ہیں، اور دونوں سروں کو اس ترتیب پر متفق ہونا پڑتا ہے۔

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

strongSwan کی NAT-traversal گائیڈ اس رویے کی وضاحت کرتی ہے، MOBIKE استعمال ہونے پر پورٹ کے تیرنے کے تعامل سمیت۔

اپنے بیک اینڈ کی اپنی ترتیب استعمال کریں

strongSwan میں دو کنفیگریشن بیک اینڈ ہیں، اور کلید ان میں مختلف ہے۔ swanctl.conf کنکشن encap لیتا ہے، جبکہ پرانا ipsec.conf کنکشن forceencaps لیتا ہے۔ ایک بیک اینڈ کا کلیدی لفظ دوسرے میں ڈالنا ایسی ترتیب بناتا ہے جو بغیر شکایت لوڈ ہوتی ہے اور کچھ نہیں بدلتی، جو غلطی سے بھی بدتر ہے۔

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

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

لپٹے ہوئے ڈیٹا کی تصدیق کریں، صرف پورٹ کی نہیں

محفوظ ٹریفک بہتے وقت گیٹ وے پر کیپچر کریں، پھر اس کا موازنہ strongSwan کے اپنے نظریے سے کریں:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP IP پروٹوکول 50 کے طور پر نظر آتا ہے اور UDP جیسا بالکل نہیں لگتا۔ لپٹا ہوا ESP 4500 پر UDP ڈیٹاگرام کے طور پر نظر آتا ہے جن کا پے لوڈ IKE نہیں۔ اسی پورٹ پر IKE ٹریفک انکیپسولیشن کا ثبوت نہیں ہے، کیونکہ MOBIKE IKE کو وہاں منتقل کر سکتا ہے جبکہ ڈیٹا راستہ native رہتا ہے، اس لیے پورٹ نمبر نہیں، پے لوڈ پڑھیں۔

راستے کے MTU کو بھی ذہن میں رکھیں۔ غلاف اضافی خرچ شامل کرتا ہے، اور native ESP اٹھانے والے راستے کو پیکٹ بڑھنے پر ایڈجسٹمنٹ درکار ہو سکتی ہے۔ مطلوبہ ICMP ہینڈلنگ پہلے ہی ڈیزائن کا حصہ ہونی چاہیے؛ انکیپسولیشن اس انحصار کو ختم نہیں کرتا۔

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