آپ کا LAN کسی VPN کلائنٹ پر موجود سروس تک کیوں نہیں پہنچتا

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

ٹوٹی ہوئی ٹنل نہیں

دونوں سرے نجی حدود پر بیٹھے ہیں، یہ عام صورت ہے اور غلط ترتیب نہیں۔ 10.8.0.6 جیسا پتہ ٹنل کے اندر حقیقی ہے اور کہیں اور موجود نہیں، اس لیے LAN کے پاس وہاں کچھ بھیجنے کی کوئی وجہ نہیں۔ راؤٹنگ کو چھونے سے پہلے تصدیق کریں کہ سروس ٹنل کے اندر پہنچ کے قابل ہے بھی یا نہیں: کلائنٹ پر ss -ltn دکھاتا ہے کہ سننے والا 127.0.0.1، LAN انٹرفیس یا ٹنل پتے سے بندھا ہے۔ صرف loopback سے بندھا ڈیمن اپنے سوا کسی کو جواب نہیں دیتا، اور کوئی روٹ، DNAT یا پورٹ فارورڈنگ اسے نہیں بدلتی۔

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

روٹ کی شکل: LAN کو بتائیں کہ تالاب کہاں ہے

LAN گیٹ وے پر مستقل روٹ سب سے صاف جواب ہے جب LAN اور ٹنل کا تالاب ایک دوسرے پر نہ آئیں۔ تالاب کو اس مشین کی طرف موڑیں جو ٹنل ختم کرتی ہے:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

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

push "route 192.168.1.0 255.255.255.0"

اس سب نیٹ کے لیے جو سرور کے پیچھے نہیں بلکہ ایک کلائنٹ کے پیچھے ہے، سرور کو نظام کا روٹ اور اس کلائنٹ کی فائل میں iroute اندراج (client-config-dir کے تحت) دونوں چاہئیں۔ iroute کے بغیر، OpenVPN جانتا ہے کہ سابقہ موجود ہے اور اسے معلوم نہیں کہ کون سا کلائنٹ اس کا مالک ہے: پیکٹ آتے ہیں اور ڈیمن کے پاس انہیں ملانے کے لیے کچھ نہیں ہوتا۔

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

NAT کی شکل: اندر DNAT، اور وہ SNAT سطر جسے سب چھوڑ دیتے ہیں

جب آپ LAN گیٹ وے کو نہیں چھو سکتے، یا بالکل ایک پورٹ شائع کرنا چاہتے ہیں، VPN ہوسٹ پر ترجمہ LAN پر کسی بھی روٹ کے بغیر کام کرتا ہے۔ پورٹ شائع کریں، اسے آگے بھیجیں، اور ٹنل میں جاتے راستے میں ماخذ کا ترجمہ کریں:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

تیسری سطر وہی ہے جو غائب ہو جاتی ہے۔ اسے چھوڑ دیں اور کلائنٹ اصل LAN پتے کو ماخذ کے طور پر دیکھتا ہے، اپنے طے شدہ روٹ سے جواب دیتا ہے، اور وہ جواب LAN کی طرف لوٹنے کے بجائے ٹنل میں چلا جاتا ہے۔ کنکشن بچے گا یا نہیں، یہ پھر اس راؤٹنگ پر منحصر ہے جس کی آپ نے کبھی منصوبہ بندی نہیں کی۔ SNAT کے ساتھ کلائنٹ سرور کا ٹنل پتہ دیکھتا ہے، اس لیے جواب ٹنل سے ہوتا ہوا واپس اس واحد ہوسٹ تک جاتا ہے جو ترجمہ واپس کر سکتا ہے۔

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

درست نظر آنے والا قاعدہ پیکٹ پھر بھی کیوں گراتا ہے

ان ناکامیوں کی اکثریت اس قاعدے میں نہیں جسے آپ گھور رہے ہیں۔ اس ترتیب سے چار چیزیں جانچیں، اور جہاں پہلی نہ ملے وہیں رک جائیں:

• چین کی ترتیب۔ iptables -I اوپر داخل کرتا ہے اور -A آخر میں جوڑتا ہے، اس لیے پہلے والا اجازت دینے یا روکنے والا قاعدہ پہلے فیصلہ کرتا ہے۔
• غلط چین۔ خود راؤٹر کو مخاطب ٹریفک INPUT سے گزرتی ہے، اور آگے بھیجی گئی ٹریفک اسے کبھی نہیں چھوتی۔ ایک سروس شائع کرنے کے لیے دونوں میں قواعد درکار ہو سکتے ہیں۔
• سمت کے جھنڈے۔ -i tun0 کلائنٹس سے آنے والی ٹریفک سے ملتا ہے اور -o tun0 ان کی طرف جانے والی ٹریفک سے۔ غلط جھنڈے والا REJECT وہ چیز روکتا ہے جو آپ نے نہیں چاہی تھی۔
• ماخذ کی پابندی۔ ایک کلائنٹ پتہ قبول کرنے والا فارورڈنگ اسی کلائنٹ سے کام کرتا ہے اور ہر دوسرے ماخذ کو ایک لفظ کہے بغیر گرا دیتا ہے۔

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

مقامی فارورڈنگ، جب LAN پر کچھ بھی بدلا نہیں جا سکتا

SSH مقامی فارورڈنگ پورے سوال کو نظرانداز کر دیتی ہے۔ اسے LAN پر روٹ، کلائنٹ کے فائر وال کا تعاون، اور کہیں شائع شدہ پورٹ کی ضرورت نہیں:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

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

نیا قاعدہ جوڑنے سے پہلے دونوں سمتیں جانچیں

ترجمہ نشان چھوڑتا ہے، اور انہیں پڑھنا اندازہ لگانے سے بہتر ہے۔ VPN ہوسٹ پر، conntrack -L دکھاتا ہے کہ ترجمہ ہوا بھی یا نہیں، iptables -t nat -L -n -v دکھاتا ہے کہ کاؤنٹر ہلے یا نہیں، اور tcpdump -ni any port 3000 دکھاتا ہے کہ کون سا ماخذ پتہ واقعی پہنچا۔ کلائنٹ پر، ss -ltn تصدیق کرتا ہے کہ سننے والا ایسے پتے پر ہے جہاں ٹنل پہنچ سکتی ہے۔

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