روٹر پر VPN یا پورٹ فارورڈنگ: کون جیتتا ہے؟

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

ایک پورٹ، دو دعویدار مالک

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

ترمیم سے پہلے دعویٰ لکھیں: خاندان، بیرونی پتہ، ترسیل، پورٹ اور ترجمہ شدہ ہدف۔

منزل کا ترجمہ مقامی جانچ سے پہلے چلتا ہے

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

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

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

اگر LAN میزبان ہی مطلوبہ آخری نقطہ ہے تو فارورڈنگ درست ہے اور روٹر کو اسی پورٹ پر بھی نہیں سننا چاہیے۔

ایک میپنگ رکھیں اور دوسری ہٹائیں

اس پورٹ اور خاندان کے NAT اندراجات کی فہرست بنائیں اور بچنے والا منتخب کریں:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

اسی نمبر والا TCP اندراج UDP ناکامی کے لیے غیر متعلق ہے، اور انہیں ایک ہی شے سمجھنے سے غلط اصول مٹ جاتا ہے۔ جب مقامی ساکٹ کو جیتنا چاہیے تو متصادم میپنگ کا مالک وہی ایک اندراج ہٹاتا یا دوبارہ لکھتا ہے، اور روٹر کے اپنے پورٹ کے لیے اندراج کی اجازت اپنی جگہ رہتی ہے۔ غیر متعلقہ فارورڈنگ، انتظامی راستہ اور اصولوں کے مجموعے کی نقل—سب کو اس تبدیلی سے بچنا چاہیے۔

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

باہر سے مالک کی تصدیق کریں

ہر خاندان کو الگ الگ آزمائیں، کیونکہ روٹر پر ختم ہونے والا IPv6 کنکشن اس IPv4 کنکشن کے بارے میں کچھ نہیں کہتا جسے پرانا اصول ری ڈائریکٹ کرتا ہے۔ یہ دیکھنے کے لیے کہ کون سا آخری نقطہ جواب دے رہا ہے، وصول کرنے والی خدمت کا لاگ پڑھیں، اور کلائنٹ کے کامیابی کے پیغام کو کمزور ثبوت مانیں۔ بامعنی آزمائش کے لیے نیا بہاؤ درکار ہے۔ بیرونی میزبان سے nc -zvu 203.0.113.7 1194 کے ساتھ پروب بھیجیں اور فاتح کا لاگ journalctl -u openvpn@server -n 20 سے پڑھیں۔ روٹر کا سننے والا کنکشن خود لاگ کرتا ہے، جبکہ LAN میزبان اسے اپنی خدمت میں لاگ کرتا ہے۔

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

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