OpenVPN کی route ہدایت میں wildcard کیوں کام نہیں کر سکتا

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

راستہ کیا نصب کرتا ہے، اور کیا کبھی نہیں پڑھتا

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

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

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

جب منزل واقعی ایک سابقہ ہو

اگر ہدف کوئی معروف نجی نیٹ ورک ہے تو سابقہ لکھیں۔ دستاویزی فضا سے ایک مثال کے لیے، ایک میزبان اور ایک ذیلی نیٹ ورک ایسے دکھتے ہیں:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

دونوں اندراجات پتوں اور ماسکوں کا نام لیتے ہیں، اور دونوں DNS تبدیلیوں کا مقابلہ کرتے ہیں کیونکہ ان میں کچھ بھی نام پر منحصر نہیں۔ یہی پوری خوبی ہے: راستہ ٹوپولوجی کے بارے میں ایک بیان ہے، اُس جستجو کے بارے میں نہیں جو ایک بار ہوئی۔

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

جب کام کی اکائی میزبان نام ہو

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

پراکسی کنفیگریشن فائل اس انتخاب کا اظہار کر سکتی ہے۔ نیچے دیے گئے مثالی اصول ایک ڈومین اور اس کے ذیلی ڈومینز کو پراکسی پر اور باقی سب کچھ براہ راست بھیجتے ہیں:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

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

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

پراکسی کا اختیار کیا محیط نہیں

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

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

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

دونوں راستوں کی جانچ، صرف خوشگوار والے کی نہیں

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

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