OpenVPN کے ذریعے LAN تک رسائی خراب؟ زون، روٹ اور واپسی کا راستہ جانچیں

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

LAN کی طرف جانے والے پیکٹ کو کون سا فلٹر دیکھتا ہے

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

OpenWrt اس تقسیم کو جانچنے کے قابل بناتا ہے، اور یہ فرق ایک بار پڑھنے کے قابل ہے۔ ٹنل ختم کرنے والے زون کو LAN زون کی طرف فارورڈ قاعدہ درکار ہے، جبکہ ان پٹ قاعدہ صرف راؤٹر پر چلنے والی سروسز کو کنٹرول کرتا ہے۔ چلتی ہوئی منتظمینی صفحہ کے ساتھ مردہ LAN کا ہونا اسی غائب فارورڈ قاعدہ کا عام نتیجہ ہے۔

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

ٹنل اٹھانے والے زون کے فارورڈ ہدف کو دیکھیں: accept وہی ہے جو سیڑھی کو درکار ہے، اور reject نیچے کی ہر وقت کی انتہا کی وضاحت کرتا ہے۔ دو ملحقہ سیٹنگز وہی علامت پیدا کرتی ہیں، اس لیے یہاں رہتے ہوئے انہیں خارج کریں۔ وائرلیس تنہائی تار والے ہوسٹوں کو وائرلیس کلائنٹس سے چھپاتی ہے، اور بیکار LAN ہوسٹوں کو آف لائن سمجھنے والا راؤٹر فارورڈنگ کام کرنے کے بعد بھی جواب گرا سکتا ہے۔

منقسم ٹنل کو دھکیلا گیا سابقہ کیوں درکار ہے

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

push "route 192.168.50.0 255.255.255.0"

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

ip route show | grep 192.168.50

سائٹ سے سائٹ ساتھی دھکیلنے سے زیادہ مانگتا ہے۔ سرور کو سیکھنا ہوگا کہ اس ساتھی کے پیچھے کون سے سابقے ہیں، جو اس کی client-config-dir فائل میں iroute سطر کرتی ہے، اور اس کے اپنے جدول کو ٹنل میں جانے والا مطابق راستہ بھی درکار ہے۔

جواب کو ایسا پتہ درکار ہے جہاں وہ پہنچ سکے

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

tcpdump -ni tun0 host 192.168.50.20

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

صحیح جگہ پر ختم ہونے والی سیڑھی

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

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

نام سیڑھی کے آخر میں آتے ہیں، کبھی شروع میں نہیں۔ جو شیئرنگ 192.168.50.20 کے طور پر جواب دیتی ہے مگر nas.local کے طور پر نہیں، وہ نام کے حل یا تلاش کے لاحقے کی طرف اشارہ کرتی ہے، اور فائر وال کی تدویریں ان میں سے کسی کو نہیں بدل سکتیں۔

پہلا ناکام مرحلہ لکھیں، پھر سروس پورٹس کو ان کا الگ چکر دیں، کیونکہ سننے والا اور ہوسٹ کی اجازت الگ الگ شرطیں ہیں۔ فائل شیئرنگ، ریموٹ ڈیسک ٹاپ اور کیمرہ اسٹریمز سب کو دونوں درکار ہیں، اور LAN ذیلی نیٹ پر بھروسہ کرنے والا مگر ٹنل تالاب پر نہیں، ایسا ہوسٹ فائر وال ping کامیاب رہتے ہوئے بھی کلائنٹ گرا دیتا ہے۔ جب تمام جائزے گزر جائیں اور ایپ پھر بھی ناکام ہو، تو خرابی ٹنل کے اوپر ہے: ایک انٹرفیس سے بندھی سروس، یا کلائنٹ پر مقرر پراکسی۔