route-gateway، redirect-gateway نہیں ہے: دراصل کیا بدلتا ہے
یہ آپشن صرف اُن راستوں کو اگلا ہاپ دیتا ہے جو OpenVPN انسٹال کرتا ہے۔ اسے ہٹانا دھکیلا گیا مکمل ٹنل بند نہیں کرتا، اور اصلاح ری ڈائریکشن میں ہے۔
آپ کی ٹنل اوپر آتی ہے، نجی سب نیٹ جواب دیتا ہے، اور کوئی پروفائل سے گیٹ وے لائن مٹا دے تو بھی عام براؤزنگ اب بھی VPN میں غائب ہو جاتی ہے۔ یہی امتزاج غلط ہدایت میں ترمیم کی انگلی کی چھاپ ہے۔ جو ہٹایا گیا وہ کلائنٹ کو اُن راستوں کے لیے اگلا ہاپ دیتا تھا جو یہ انسٹال کرتا ہے؛ جو ٹریفک پکڑنا جاری رکھے ہوئے تھا وہ کہیں اور سے آیا اور سرور نے اسے دھکیلا۔ کوریج اور اگلا ہاپ الگ کام ہیں، اور ان میں سے صرف ایک طے کرتا ہے کہ عوامی منزلیں ٹنل استعمال کرتی ہیں یا نہیں۔
آپ نے جو سطر ہٹائی وہ اگلا ہاپ تھی، پالیسی سوئچ نہیں
کلائنٹ جو بھی راستہ انسٹال کرتا ہے اسے اشارہ کرنے کے لیے گیٹ وے پتہ درکار ہوتا ہے، اور جب راستہ خود کوئی پتہ نہ بتائے تو گیٹ وے ہدایت اُس پتے کا ماخذ ہوتی ہے۔ اسے مٹا دیں تو اُن راستوں کے پاس لٹکنے کی جگہ نہیں رہتی، اس لیے وہ یا انسٹال نہیں ہوتے یا ایسی راہ پر اترتے ہیں جو کہیں نہیں جاتی۔ نجی سب نیٹ وہی ہے جو ایسا راستہ اٹھائے ہوئے تھا۔
اس دوران بچ جانے والے رویے کا ایک اور مصنف ہے: دھکیلے گئے بلاک میں ری ڈائریکشن آپشن، جو اپنے جھنڈوں کے مطابق عام باہر جانے والی ٹریفک کو ٹنل میں منتقل کرتا ہے۔ گیٹ وے ہٹانا نہ اسے بند کرتا ہے نہ کمزور۔ نتیجہ دونوں حالتوں میں بدترین ہے، عوامی ٹریفک اب بھی پکڑی جاتی ہے اور وہ نجی منزل جس نے ٹنل کو جائز ٹھہرایا تھا اب ناقابل رسائی ہے۔ اسی لیے اُسی جذبے سے کی گئی دوسری ترمیم بھی کچھ نہیں بدلتی۔
چار لیور، چار مختلف کام
اس بحث میں چار ہدایات ایک دوسرے کی جگہ نقل کی جاتی ہیں، اور ان میں سے صرف ایک کوریج کو کنٹرول کرتی ہے، یعنی کون سی منزلیں ٹنل سے گزرتی ہیں۔ دوسری وہ اگلا ہاپ مقرر کرتی ہے جو راستے استعمال کرتے ہیں، تیسری ایک ہی سابقہ انسٹال کرتی ہے، اور چوتھی وہ سب کچھ پھینک دیتی ہے جو سرور نے دھکیلا، بشمول وہ نجی راستے جن کی تعیناتی کو ضرورت ہے۔ جدول انہیں نام کے بجائے اس چیز کے مطابق ترتیب دیتا ہے جو منتظم بدلنا چاہتا ہے، کیونکہ الجھن ناموں ہی سے پیدا ہوتی ہے۔ انہیں چار الگ فیصلے سمجھیں اور وہ چنیں جو آپ واقعی واپس کرنا چاہتے ہیں۔
عملاً چاروں اکثر ایک ہی دھکیلے گئے بلاک میں، سطر در سطر آتے ہیں، جس سے وہ ایک ہی ترتیب کے حصے لگتے ہیں۔ ایسا نہیں ہے، اور OpenVPN کا حوالہ انہیں الگ طریقہ کار کے طور پر اسی وجہ سے درج کرتا ہے۔ یہ جاننا کہ آپ کون سا فیصلہ واپس کر رہے ہیں کام ہے؛ ترمیم ایک سطر ہے۔
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
دھکیلی گئی سطر فلٹر کریں، اگلا ہاپ رکھیں
اگر آپ جس کوریج پر اعتراض کرتے ہیں وہ دھکیلے گئے آپشن کے طور پر آتی ہے، تو تنگ جواب یہ ہے کہ اُس آپشن کو نام سے نظر انداز کریں اور دھکیلے گئے بلاک کا باقی حصہ اچھوتا چھوڑ دیں۔ فلٹر کے طور پر لکھا جائے تو یہ نیچے کی سطر جیسا دکھتا ہے، اور اس کی جگہ متاثرہ کلائنٹ کے پروفائل میں ہے، سرور کنفیگریشن میں نہیں۔
pull-filter ignore "redirect-gateway"تنگی ہی اصل بات ہے۔ چونکہ فلٹر متن کے سابقے کا موازنہ کرتا ہے، چھوٹا نمونہ اگلے ہاپ کی ہدایت سے بھی میل کھاتا ہے، جو بالکل وہی معلومات اتار دیتا ہے جن پر نجی راستے منحصر ہیں اور اصل غلطی کو نئے لباس میں دہراتا ہے۔ فلٹر صرف دھکیلے گئے آپشنوں پر عمل کرتا ہے، اس لیے وہ مقامی طور پر لکھی گئی یا نیٹ ورک مینیجر کی طرف سے مسلط کردہ مساوی سطر کو کبھی نہیں چھوتا۔ اس کے بعد دوبارہ جڑیں، کیونکہ زندہ سیشن سرور کی دھکیلی ہوئی چیز کا دوبارہ جائزہ نہیں لیتا۔
جدول نہیں، تلاش پڑھیں
پروفائل دوبارہ لوڈ کرنے کے بعد کرنل سے پوچھیں کہ دو منزلیں اصل میں کہاں جائیں گی: ایک نجی سابقے کے اندر اور ایک عوامی انٹرنیٹ پر۔ مرکزی جدول کا مکمل ڈمپ پڑھنا مشکل اور غلط پڑھنا آسان ہے، کیونکہ راستہ موجود بھی ہو سکتا ہے اور پھر بھی زیادہ مخصوص مطابقت سے ہار سکتا ہے۔ پالیسی پر مبنی روٹنگ میں قاعدہ، جدول اور ماخذ پتہ بھی جانچ کا حصہ ہیں۔
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showdef1 قسم کو جاننا چاہیے، کیونکہ یہ پرانی طے شدہ اندراج کو نظر آنے والا رکھتا ہے جبکہ آدھے طے شدہ اندراجات کی جوڑی تلاش جیت لیتی ہے۔ اس لیے آؤٹ پٹ میں 0.0.0.0/0 سطر بذات خود کچھ ثابت نہیں کرتی۔ تلاش اُس سوال کا جواب دیتی ہے جس کا جواب فہرست صرف دیتی دکھتی ہے۔
DNS، IPv6 اور نجی راستہ اب بھی کام کرنا چاہیے
ایک IPv4 ری ڈائریکشن سے انکار کرنا حل کنندہ کے بارے میں کچھ نہیں کہتا، اس لیے دھکیلا گیا DNS آپشن راستوں کے درست دکھنے کے دوران بھی سوالات ٹنل میں بھیجنا جاری رکھ سکتا ہے۔ IPv6 طے شدہ اُس پتہ خاندان کے لیے یہی کر سکتا ہے جسے IPv4 جانچ نے کبھی نہیں چھوا۔ دونوں کو اندازے کے بجائے واضح فیصلہ چاہیے۔ پھر تصدیق کریں کہ نجی سروس اب بھی جواب دیتی ہے، کیونکہ نجی راستہ کھو دینے والی منقسم ٹنل منقسم ٹنل نہیں ہے، وہ ٹوٹی ہوئی ہے۔
ایک وسیع تر آلہ تنبیہ کا حقدار ہے: route-nopull ہر دھکیلے گئے راستے اور ہر دھکیلے گئے DNS آپشن کو پھینک دیتا ہے، جو مکمل ٹنل کو یقینی طور پر روکتا ہے اور تعیناتی جن نجی راستوں پر منحصر ہے انہیں بھی اتنی ہی یقین سے توڑتا ہے، اس لیے یہ ایک آپشن پر نشانہ لگائے نامی فلٹر سے کہیں بڑا ہتھوڑا ہے۔ کسی بھی تبدیلی کے بعد نجی منزل، عوامی منزل اور حل کنندہ جانچیں، اور مکمل ہونے والے مصافحے کو مصافحے کے سوا کسی اور چیز کا ثبوت نہ سمجھیں۔