VPN کے مخصوص پتے پر دراصل کون جواب دیتا ہے؟

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

پتے کے پیچھے پیکٹ کا راستہ

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

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

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

نمونہ A: گیٹ وے پتے کا مالک ہے

پہلے نمونے میں گیٹ وے خود پتہ رکھتا ہے، یا موجودہ انٹرفیس پر ثانوی پتے کے طور پر، یا مخصوص انٹرفیس پر پتے کے طور پر، یا loopback کے طور پر جسے پلیٹ فارم سرنگ کے آخری نقطے کے طور پر تائید کرتا ہے۔ یہ تین مختلف خصوصیات ہیں جن کے تین مختلف ترتیب کے راستے ہیں، اور ایک کی تائید کرنے والا پلیٹ فارم باقیوں کی نہ بھی کرے۔

اس کے گرد ڈیزائن کرنے سے پہلے تصدیق کریں کہ پلیٹ فارم اور ورژن بالکل اسی ترتیب کی تائید کرتے ہیں۔ روٹ شدہ بلاک، انٹرفیس پر اضافی پتہ اور loopback آخری نقطہ آپس میں بدلے نہیں جا سکتے، اور ایک ورژن کی دستاویز اگلے کے اسی برتاؤ کا وعدہ نہیں کرتی۔

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

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

ٹوپولوجی میں کہیں اور پہلے سے موجود سب نیٹ میں دوسرا انٹرفیس نہ رکھیں اور یہ نہ سمجھیں کہ پلیٹ فارم اسے سنبھال لے گا۔ اوورلیپ ہوتے انٹرفیس سب نیٹ غیر واضح ماخذ انتخاب پیدا کرتے ہیں اور کئی پلیٹ فارمز پر ترتیب دینے سے مکمل انکار کرتے ہیں۔

نمونہ B: اوپری آلہ اس کا ترجمہ کرتا ہے

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

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

دونوں پتے درج کریں: وہ جس سے ساتھی رابطہ کرتے ہیں اور وہ جو گیٹ وے واقعی دیکھتا ہے۔ پھر نقل و حمل اور واپسی راستہ درج کریں، کیونکہ UDP 500 کے لیے کام کرنے والا مگر انکیپسولیٹڈ ESP کے لیے نہ کام کرنے والا ترجمہ جڑ جائے گا اور پھر ٹریفک لے جانے میں ناکام ہوگا، جو بعد میں ڈیبگ کرنے کے لیے الجھا دینے والی ناکامی ہے۔

شناخت بیرونی پتہ نہیں ہے

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

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

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

ایک کنکشن دیکھ کر ڈیزائن قبول کریں

جانچیں کہ نیا مجاز کنکشن دراصل کہاں پہنچایا جاتا ہے، کون سی شناخت جواب دیتی ہے، اور پھر کون سا نجی بہاؤ اجازت یافتہ ہوتا ہے۔ تین مشاہدے، تین مختلف تہیں، اور پتے کی کامیاب عوامی تلاش ان میں سے کسی ایک کی بھی جانچ نہیں کرتی۔

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

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