NAT کے ذریعے L2TP/IPsec: اصل میں کیا ٹوٹتا ہے اور کیوں

یہ دعویٰ کہ NAT، L2TP/IPsec کو توڑتا ہے آدھا سچ ہے اور اسی لیے بیکار ہے۔ پتوں کا ترجمہ عام بات ہے، NAT traversal بالکل اسی سے بچنے کے لیے موجود ہے، اور روزانہ لاکھوں کلائنٹ راؤٹر کے پیچھے سے جڑتے ہیں۔ جو ٹوٹتا ہے وہ ایک مخصوص تبادلے کا ایک مخصوص مرحلہ ہے: IKE کو کبھی جواب نہیں ملتا، انکیپسولیٹڈ ٹنل ایسی پالیسی سے گرا دی جاتی ہے جو صرف ایک پروٹوکول کی اجازت دیتی ہے، یا ٹنل کے بیکار رہنے کے دوران میپنگ ختم ہو جاتی ہے۔ ایک بار معلوم ہو جائے کہ آپ کس مرحلے پر ہیں، تو حل عام طور پر ایک قاعدہ یا keepalive ہوتا ہے، نیا VPN ڈیزائن نہیں۔

افسانہ ہی غلط سوال ہے

مفید سوال یہ نہیں کہ «کیا NAT اسے توڑتا ہے» بلکہ یہ ہے کہ «تبادلے کا کون سا حصہ ترجمہ ہوتا ہے، اور ترجمہ کرنے والا آلہ اس کے ساتھ کیا کرتا ہے»۔ L2TP/IPsec ایک تہوں والا پروٹوکول ہے: IKE بات چیت کرتا ہے، ESP حفاظت دیتا ہے، اور L2TP اسی حفاظت کے اندر PPP لے کر جاتا ہے۔ پتوں کا ترجمہ ہر تہہ پر مختلف اثر ڈالتا ہے، اور ناکامی کے نشانات الگ پہچانے جا سکتے ہیں اگر آپ خرابی کے ڈائلاگ کے بجائے بات چیت کے مرحلے کو دیکھیں۔

کامیابی سے ویب براؤز کرنے والا راؤٹر صرف یہ ثابت کرتا ہے کہ ماخذ پورٹ ترجمے کے ساتھ TCP کام کرتا ہے۔ یہ UDP 500، UDP 4500 یا پروٹوکول 50 کے بارے میں کچھ نہیں کہتا، اور یہ تعیناتی انہی تین چیزوں پر منحصر ہے۔

مرحلہ 1: IKE کو جواب تو ملنا ہی چاہیے

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

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

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

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

مرحلہ 2: انکیپسولیشن بدل دیتا ہے کہ فائر وال کیا دیکھتا ہے

ESP ایک IP پروٹوکول ہے، TCP یا UDP پورٹ نہیں، اور عام پورٹ پتہ ترجمے میں دوبارہ لکھنے کے لیے کوئی پورٹ فیلڈ نہیں ہوتی۔ اسی لیے NAT traversal محفوظ پے لوڈ کو UDP 4500 میں منتقل کرتا ہے: انکیپسولیشن ترجمہ کرنے والے آلے کو وہ دیتا ہے جس کا ترجمہ وہ جانتا ہے۔ ایسا ہوتے ہی، صرف UDP 500 کے لیے لکھا گیا فائر وال قاعدہ بات چیت کی اجازت دے کر ٹنل گرا دے گا، جس سے وہ الجھا ہوا نتیجہ ملتا ہے جہاں لاگ کامیاب مرحلہ 1 اور کوئی ٹریفک نہ ہونے کی نشاندہی کرتا ہے۔

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

پروٹوکول 50 اب بھی ترجمے کے بغیر راستوں پر اور ان راستوں پر اہم ہے جہاں درمیانی باکس اسے اجازت دینے کے لیے ترتیب دیا گیا ہے۔ اگر آپ خارج کر کے تشخیص کرتے ہیں، تو قواعد ڈھیر میں بڑھانے کے بجائے مفروضہ بند کریں: 500، 4500 اور ESP کی اجازت دیں، تصدیق کریں کہ ٹنل اوپر آتی ہے، پھر جو غیر ضروری نکلا اسے ہٹا دیں۔ جس قاعدے کو کوئی سمجھا نہ سکے وہ ایسا قاعدہ ہے جسے اگلی رکاوٹ کا سبب بننے پر کوئی نہیں ہٹائے گا۔ تنگ کرنے کو تبدیلی کے ریکارڈ میں اس مرحلے کے ساتھ لکھیں جسے اس نے درست کیا، تاکہ اگلا انجینئر اسی انگوٹھے کے قاعدے سے نہیں، آپ کے شواہد سے شروع کرے۔

مرحلہ 3: میپنگ ختم ہوتی ہے اور ٹنل مر جاتی ہے

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

مردہ ساتھی کی نشاندہی اور NAT keepalive اسی لیے ہیں، اور دونوں سروں کو انہیں بھیجنے کے لیے تیار ہونا چاہیے۔ اگر آپ کا سرور ترجمے کے پیچھے ہے، تو Windows کی طرف ضرورت ایک دستاویزی رجسٹری ترتیب ہے جو سرور کو اپنے جانے والے پیکٹوں کے لیے UDP انکیپسولیشن فرض کرنے پر مجبور کرتی ہے؛ اس کے بغیر جواب دینے والا ESP بھیجتا ہے جسے ترجمہ کرنے والا آلہ واپس میپ نہیں کر سکتا۔ یہ سرور کی ترتیب کا معاملہ ہے، کلائنٹ کا نہیں۔

WAN پتہ بدلنے سے دوسری سمت سے وہی نتیجہ آتا ہے: میپنگ نئے پتے کے گرد دوبارہ بنتی ہے، اور پرانا حفاظتی ربط اب ایسے جوڑے کی طرف اشارہ کرتا ہے جو اب موجود نہیں۔ دوبارہ جڑنے کا طرز عمل کلائنٹ کے نفاذ کا حصہ ہے، اسی لیے «راؤٹر ری بوٹ کے بعد دوبارہ جڑیں» ایک کلائنٹ پر کام کرتا ہے اور دوسرے پر دستی ٹوگل درکار ہے۔

آپریٹر گریڈ NAT کے پیچھے ہوسٹنگ ایک الگ مسئلہ ہے

اگر آپ گھر پر L2TP/IPsec سرور ہوسٹ کر کے باہر سے اس تک پہنچنا چاہتے ہیں، تو ضرورت بلا طلب آنے والی رسائی ہے، اور NAT traversal یہ نہیں دیتا۔ آپ کے راؤٹر کے سامنے آپریٹر گریڈ NAT کا مطلب ہے کہ ایسا کوئی پورٹ نہیں جسے فارورڈ کر کے آپ قابل رسائی بن سکیں، کیونکہ عوامی پتہ مشترک ہے اور میپنگ صرف جانے والی ہے۔

کوئی IPsec پاس تھرو چیک باکس اسے نہیں بدلتا، اور کوئی کلائنٹ ترتیب اس کی تلافی نہیں کرتی۔ معاون جوابات واقعی قابل رسائی پتہ، ہوسٹ شدہ آخری نقطہ، یا ایسی ساخت ہیں جس میں ہر شریک جانے والا کنکشن بناتا ہے۔ UDP انکیپسولیشن تفصیل موجود بہاؤں کے لیے ترجمے کا مسئلہ حل کرتی ہے؛ جہاں آپریٹر پیش نہیں کرتا وہاں یہ آنے والا راستہ نہیں بناتی۔

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