خالی VPN ٹیبل بذات خود کچھ نہیں روکتا

پالیسی قاعدہ نشان زدہ پیکٹ ایک مخصوص ٹیبل میں بھیجتا ہے، اور عام توقع یہ ہے کہ VPN راستہ کھو جانے پر وہ روک دیے جائیں گے۔ مگر طریقہ کار کچھ اور کرتا ہے۔ جب ٹیبل میں کوئی مطابق راستہ نہ ہو، تلاش اگلے قاعدے کی طرف جاری رہتی ہے رکنے کے بجائے، اور main ٹیبل میں اب بھی uplink کے لیے ایک عام طے شدہ راستہ موجود ہے۔ نتیجہ ایسی ترتیب ہے جو fail-closed دکھتی ہے مگر fail-open کی طرح برتاؤ کرتی ہے۔

کچھ بگڑا نہیں؛ پالیسی پر مبنی روٹنگ اسی طرح متعین ہے۔

جب ٹیبل میں کچھ نہ ہو تو تلاش جاری رہتی ہے

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

وہ قواعد کا مجموعہ لیں: نشان زدہ تلاش ٹیبل 42 میں جاتی ہے، اور بعد کا قاعدہ وہی نشان default نامی ٹیبل میں بھیجتا ہے۔ جب تک ٹیبل 42 میں قابل استعمال طے شدہ راستہ موجود ہے، پہلی تلاش راستہ فراہم کرتی ہے۔ جب وہ راستہ غائب ہو جائے اور ٹیبل 42 میں اور کچھ مطابق نہ ہو، تلاش رد میں تبدیل نہیں ہوتی؛ پروسیسنگ اگلے قاعدے کی طرف جاتی ہے، اور جب وہ بھی کچھ نہ پائے تو main ٹیبل تک پہنچتی ہے۔ اُس ترتیب میں کچھ بھی کون سے قاعدے نے حتمی جواب دیا کی اطلاع نہیں دیتا، اس لیے کام کرنے والا کنکشن کام کرنے والی پالیسی جیسا دکھتا ہے۔

ٹیبل 253، جسے روایتی طور پر default کہا جاتا ہے، ایک عام روٹنگ ٹیبل ہے اور عام طور پر خالی ہوتا ہے۔ اس کا نام پیکٹ پھینکنے کا حکم نہیں ہے، اور یہ ٹیبل کے اندر طے شدہ منزل کے راستے کے برابر نہیں ہے۔

ٹرمینل عمل تلاش ختم کرتے ہیں

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

خالی ٹیبل کی تلاش کے بجائے VPN تلاش کے بعد ایک ٹرمینل قاعدہ آ سکتا ہے۔ اسی نشان کے ساتھ، ٹیبل 42 کے قاعدے کے بعد رکھا گیا prohibit عمل اُس ٹیبل سے کچھ نہ ملنے پر تلاش ختم کرتا ہے اور main ٹیبل کو ایک اور موقع دینے کے بجائے انتظامی انکار واپس کرتا ہے۔ Unreachable اور blackhole بھی ٹرمینل ہیں، بھیجنے والے کے لیے مختلف خطا برتاؤ کے ساتھ۔

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

اصل نشان اور انٹرفیس سے تصدیق کریں

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

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

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

دو ناکامی کی حالتیں، ایک نہیں

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

ایسا قاعدہ صرف تب تک مدد دیتا ہے جب تک یہ موجود ہے اور پیکٹ اب بھی وہ نشان اٹھائے ہوئے ہیں جو اِسے چنتا ہے۔ وہ شٹ ڈاؤن اسکرپٹ جو قاعدہ مٹا دے، یا وہ راستہ جو نشان ہٹا دے، کھلا برتاؤ بحال کر دیتا ہے۔ اُن تبدیلیوں کی مشق کرنا لائق ہے۔

پالیسی کو IPv6 پر الگ سے لاگو کریں، اور منظور شدہ اینڈ پوائنٹ استثنائیں واضح رکھیں، مبہم نہیں۔