LAN کلائنٹ راؤٹر VPN کو نظر انداز کرتے ہیں جب تک پالیسی راؤٹنگ فعال نہ ہو
فارورڈ قواعد پیکٹوں کی اجازت دیتے ہیں، مگر کبھی انٹرفیس منتخب نہیں کرتے۔ الگ پالیسی جدول اور قاعدہ طے کرتے ہیں کہ کون سے LAN کلائنٹ راؤٹر VPN استعمال کرتے ہیں۔
راؤٹر اپنی ٹنل کے ذریعے انٹرنیٹ تک پہنچتا ہے، جبکہ اس کے پیچھے موجود لیپ ٹاپ اب بھی ISP کا پتہ بتاتا ہے۔ قبولیت کے قواعد شامل کرنے سے فائدہ نہیں ہوتا، اور یہ ناکامی سبق آموز ہے: فلٹرنگ بتاتی ہے کہ پیکٹ گزر سکتا ہے یا نہیں، یہ نہیں کہ وہ کہاں جاتا ہے۔ انٹرفیس کا انتخاب پہلے ہی ایک راؤٹنگ تلاش نے کر لیا ہے جسے آپ کی کلائنٹ فہرست کے بارے میں کچھ معلوم نہیں۔ تلاش درست کریں، پھر فائر وال مزید مشتبہ نہیں رہے گا۔
فلٹر قاعدہ انٹرفیس منتخب نہیں کر سکتا
لینکس راؤٹر پر پیکٹ کا بہاؤ پہلے راؤٹنگ فیصلہ چلاتا ہے اور پھر فارورڈ ہک۔ جب کوئی قاعدہ باہر جانے والے ٹنل ڈیوائس سے مماثل ہوتا ہے، تب تک کرنل فیصلہ کر چکا ہوتا ہے کہ ٹنل ہی باہر جانے کا راستہ ہے۔ اگر مرکزی جدول اب بھی WAN کے طے شدہ راستے کو ترجیح دیتا ہے، تو پیکٹ ISP کی طرف ہے اور آپ نے ابھی لکھا قبولیت کا قاعدہ اسے کبھی نہیں دیکھتا۔ ترتیب کا یہی ایک حقیقت بتاتی ہے کہ نئے فائر وال قواعد کا پورا صفحہ کیوں کچھ نہیں بدلتا۔
نیچے کی مثال br-lan پر 192.168.8.0/24 کا LAN، ٹنل ڈیوائس tun0، اور 192.168.8.23 پر ایک سیٹ ٹاپ باکس استعمال کرتی ہے جسے ٹنل استعمال کرنا چاہیے۔
قواعد میں ترمیم سے پہلے تلاش پڑھیں
کرنل سے کہیں کہ وہ اس کلائنٹ کی جانب سے راستہ حل کرے۔ جواب میں باہر جانے والی ڈیوائس اور وہ ماخذ پتہ ہوتا ہے جو منتخب ہوگا، اور تشخیص کی تصدیق کے لیے بس اتنا ہی درکار ہے۔ اگر جواب WAN ڈیوائس کا نام لے، تو پیکٹ کو آپ کے قاعدے تک پہنچنے کا کوئی موقع نہیں تھا۔
ip -4 route get 198.51.100.7 from 192.168.8.23
اس کلائنٹ کے لیے سوال دہرائیں جسے عام راستے پر رہنا چاہیے۔ جب دونوں جواب ایک ہی ڈیوائس کا نام لیں، تو ماخذ کی بنیاد پر پالیسی ابھی نافذ نہیں، اور اصلاح فلٹرنگ میں نہیں، راؤٹنگ میں ہے۔
جن کلائنٹوں کو ڈھانپنا ہے ان کے ساتھ جدول منسلک کریں
پالیسی راؤٹنگ مرکزی جدول سے پہلے قواعد کی تلاش داخل کرتی ہے۔ ایسا جدول بنائیں جس کا طے شدہ راستہ ٹنل ہو، پھر اس جدول کو منتخب کنندہ سے باندھیں: ان پٹ انٹرفیس، ماخذ پتہ یا فائر وال نشان۔ ترجیحات ترتیب طے کرتی ہیں، اور مرکزی جدول فہرست میں بہت نیچے 32766 پر ہے، اس لیے کم نمبر والا قاعدہ پہلے دیکھا جاتا ہے۔ انٹرفیس منتخب کنندہ پل پر ہر کلائنٹ کو ڈھانپتے ہیں؛ پتہ منتخب کنندہ ایک مشین کو ڈھانپتے ہیں۔
ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200
فرم ویئر انٹرفیس عام طور پر وہی اشیاء دکھاتے ہیں جو پالیسی راؤٹنگ یا VPN پالیسی کا صفحہ دکھاتا ہے۔ وہاں ڈیوائس فہرست ہاتھ سے لکھے قواعد کے مقابلے میں سنبھالنا آسان ہے اور قواعد کی نحو بدلنے والی اپ گریڈ کے بعد بھی عام طور پر قائم رہتی ہے۔
منتخب کنندہ جان بوجھ کر چنیں۔ انٹرفیس قاعدہ مختصر اور مستقبل کے لیے محفوظ ہے، مگر وہ اسی پل پر آنے والی راؤٹر کی اپنی انتظامی ٹریفک بھی پکڑ لیتا ہے۔ ماخذ قاعدہ درست ہے اور ڈیوائس فہرست بدلنے پر ہر بار ترمیم چاہتا ہے۔ انتخاب لکھ رکھیں، کیونکہ ایک ڈیوائس مختلف کیوں برتاؤ کرتا ہے یہ پوچھنے والے اگلے شخص کو اس کی ضرورت ہوگی۔
مقامی منزلوں کو ٹنل سے باہر رکھیں
نیا جدول صرف وہی راستے جانتا ہے جو آپ اس میں ڈالتے ہیں۔ LAN سابقہ نہیں ہے، اس لیے پرنٹر اور NAS کی ٹریفک ٹنل کے طے شدہ راستے پر چل کر غائب ہو جاتی۔ throw راستہ اس جدول میں تلاش ختم کرتا ہے اور فیصلہ مرکزی جدول کو واپس دیتا ہے۔
ip -4 route add throw 192.168.8.0/24 table 200
وہ راستہ چھوڑ دیں تو مقامی شیئرنگ ٹوٹ جاتی ہے، اور اگر منتخب کنندہ ارادے سے زیادہ وسیع ہو تو راؤٹر کا اپنا انتظامی سیشن بھی غائب ہو سکتا ہے۔ پھر ماخذ کا سوال طے کریں: جو ٹنل پیکٹ اب بھی LAN پتے رکھتے ہیں انہیں دور والے سرے کا واپسی راستہ جاننا ضروری ہے، جبکہ ٹنل پر masquerading اس شرط کو ہٹا دیتا ہے اور دور والے سرے کو نظر آنے والی کلائنٹ شناخت بھی ہٹا دیتا ہے۔
چلنے کے دوران شامل کیے گئے قواعد اور راستے دوبارہ آغاز یا فرم ویئر اپ ڈیٹ کے بعد غائب ہو جاتے ہیں۔ انہیں راؤٹر کے آغاز کے نظام میں شامل کریں، ایک بار دوبارہ آغاز کریں، اور کلائنٹ سے پھر جانچیں: اس کا عوامی پتہ، WAN پر رہنے والا دوسرا کلائنٹ، اور نئے کنکشن کے دوران ٹنل کاؤنٹر۔