ایک OpenVPN پورٹ، تین خدمات: اندرونی پورٹ کیوں اہم ہیں

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

بیرونی بہاؤ کیا لے کر جاتا ہے، اور کیا چھپاتا ہے

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

لہٰذا WAN انٹرفیس پر کیپچر تین نہیں، ایک گفتگو دکھاتا ہے۔ اندرونی پورٹیں صرف ڈی کیپسولیشن کے بعد ظاہر ہوتی ہیں۔ اسی لیے ایک فائر وال سوراخ SSH، HTTPS اور DNS ایک ہی وقت میں لے جا سکتا ہے۔

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

TUN/TAP دستاویز اُس حوالگی کی وضاحت کرتی ہے جہاں راستہ بند TUN ڈیوائس کرنل اور صارف اسپیس پروسیس کے درمیان IP پیکٹ منتقل کرتی ہے۔ یہی حوالگی اندرونی ہیڈر کو گیٹ وے کے روٹنگ اور فائر وال کوڈ کے لیے نظر آنے والا بناتی ہے۔ یہ بھی بتاتی ہے کہ بیرونی پورٹ اِس بارے میں کچھ کیوں نہیں کہتی کہ کون سی خدمات کی اجازت ہے۔

NAT فارورڈنگ سامع کی ہے، ایپلیکیشنز کی نہیں

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

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

رسائی واقعی اندرونی پالیسی میں طے ہوتی ہے

خفیہ کاری راستے کی حفاظت کرتی ہے؛ یہ منزل کو اختیار نہیں دیتی۔ کلائنٹ راستے چنتے ہیں کہ کون سے سابقے ٹنل میں داخل ہوں، گیٹ وے کی فارورڈنگ پالیسی طے کرتی ہے کہ پیکٹ اُس سے نکل سکتے ہیں یا نہیں، اور منزل کی فائر وال اور لاگ ان طے کرتے ہیں کہ خدمت جواب دے گی یا نہیں۔ DNS سب سے واضح معاملہ ہے: سوالات لے جانا حل کنندہ کو یہ نہیں بناتا کہ وہ اُنہیں آپ کے کلائنٹ پول سے قبول کرے۔ ہر پرت آزادانہ نہیں کہہ سکتی۔

ٹنل کے ذریعے ہر خدمت کو الگ الگ جانچیں۔ کامیاب تلاش ویب پورٹ کے بارے میں کچھ نہیں کہتی، اور کامیاب ویب درخواست SSH کے بارے میں کچھ نہیں کہتی۔

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

جب ٹنل چل رہا ہو اور سب ناکام ہو، پہلے کلائنٹ کی روٹ ٹیبل پڑھیں۔ جب ایک خدمت ناکام ہو اور باقی چلیں، خرابی اسی منزل پر ہے۔ یہ دونوں مشاہدے مختلف ذمہ داروں کی طرف اشارہ کرتے ہیں، اور اُنہیں ملانا وقت ضائع کرتا ہے۔

WireGuard بھی وہی لکیر کھینچتا ہے

WireGuard اپنے بیرونی سامع کو ListenPort کا نام دیتا ہے، اور اندرونی ایپلیکیشن پھر بھی وہی خدمت پورٹ استعمال کرتی ہے جس کی اُسے ضرورت ہے۔ AllowedIPs راستہ بند سابقوں کا مجموعہ ہے، اجازت یافتہ خدمت پورٹس کی فہرست نہیں۔ اِسے پورٹ اجازت فہرست کے طور پر پڑھنا ایسے اصول بناتا ہے جو ٹنل کے کام سے مطابقت نہیں رکھتے۔ نام مختلف ہیں؛ تہہ بندی مختلف نہیں۔

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

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