ڈومین کی بنیاد پر VPN روٹنگ بمقابلہ IP روٹس: کون سا موزوں ہے؟
اسپلٹ ٹنل باکس میں ہوسٹ نام کوئی روٹ نہیں ہے۔ ڈومین قواعد اور واضح سابقوں کا موازنہ تازہ کاری، ذیلی ڈومینز کے دائرہ کار اور DNS بدلنے پر ہونے والے اثرات کے حوالے سے کریں۔
ایک IP روٹ ایڈریس کے سابقے سے مماثل ہوتا ہے، اور کرنل مزید سوالات پوچھے بغیر اسے لاگو کرتا ہے۔ ڈومین کی بنیاد پر VPN قاعدہ نام سے مماثل ہوتا ہے، یعنی اسٹیک میں کسی چیز کو فیصلہ کرنا ہوتا ہے کہ وہ نام اس وقت کون سے ایڈریسز کی نشاندہی کرتا ہے اور اس فیصلے کو تازہ رکھنا ہوتا ہے۔ یہ مختلف ناکامی کے طریقوں والے مختلف میکانزم ہیں، اور بیچنے والے دونوں کے لیے ایک ہی لفظ استعمال کرتے ہیں۔ خصوصیات کی فہرستوں میں ان کا موازنہ کرنا اصل بات سے محروم ہو جاتا ہے؛ ان کا موازنہ اس بات پر کریں کہ جواب بدلنے پر کیا ہوتا ہے۔
مفید تقسیم اس قاعدے کے درمیان ہے جو حل کرتا ہے اور اس قاعدے کے درمیان جو نہیں کرتا۔
ہر قاعدہ دراصل کس سے مماثل ہے
سابقے کا قاعدہ روٹنگ ٹیبل میں منزل کے ایڈریسز سے مماثل ہوتا ہے۔ کچھ حل نہیں ہوتا، کچھ ختم نہیں ہوتا، اور ہر پیکٹ کے لیے مماثلت درست ہوتی ہے۔ ڈومین کا قاعدہ کسی ایپلیکیشن کی نام کی درخواست سے مماثل ہوتا ہے، جسے RFC 1034 ایڈریس کے بجائے لیبلوں کے درخت کے طور پر بیان کرتا ہے۔ کچھ مصنوعات نام ایک بار حل کر کے حاصل شدہ ایڈریسز کو روٹس کے طور پر نصب کرتی ہیں، جس سے قاعدہ تازہ کاری ٹائمر کے ساتھ منسلک IP قاعدہ بن جاتا ہے۔
ڈیبگ کرنے سے پہلے جان لیں کہ ان دونوں میں سے کون سا آپ کے پاس ہے، کیونکہ ہر صورت میں ناکامی بالکل مختلف دکھائی دیتی ہے۔
ڈومین قاعدہ اسٹیک میں کہاں رہتا ہے
اگر مصنوعہ ڈومین قواعد کو مقامی پراکسی کے ذریعے نافذ کرتی ہے، تو ٹریفک کو اس پراکسی تک پہنچنا ہوگا، اور سسٹم پراکسی کو نظرانداز کرنے والی ایپلیکیشنز قاعدے کو مکمل طور پر بائی پاس کر دیتی ہیں۔ اگر یہ انہیں نام حل کر کے روٹس شامل کرنے سے نافذ کرتی ہے، تو ایڈریسز صرف آخری تازہ کاری تک تازہ ہوتے ہیں۔ اگر یہ حل کنندہ سے جڑ جاتی ہے، تو DNS کا رویہ روٹنگ پالیسی کا حصہ بن جاتا ہے، اور متبادل حل کنندہ اسے خاموشی سے منسوخ کر سکتا ہے۔
سیٹنگ کا لیبل نہیں، بیچنے والے کا ماڈل پڑھیں۔ Split Tunnel کے نام والے باکس والے دو کلائنٹ تین مختلف کام کر رہے ہو سکتے ہیں۔
موازنہ کریں کہ کیا ٹوٹتا ہے
تین چیزیں مختلف طریقوں سے ٹوٹتی ہیں۔ ایڈریسز کی تبدیلی: CDN ہوسٹ نام چند منٹوں میں مختلف ایڈریس مجموعے میں حل ہو سکتا ہے، اس لیے نقل شدہ فہرست جلد پرانی ہو جاتی ہے۔ ذیلی ڈومینز کا دائرہ کار: example.com کا قاعدہ api.example.com کو محیط ہو سکتا ہے یا نہیں، اور دستاویزات عام طور پر واضح کرتی ہیں کہ کون سا۔ حل کی ناکامی: جب حل کنندہ ناکام ہوتا ہے، تو حل کرنے والا کلائنٹ ٹریفک کو ٹنل کرنے یا اسے براہ راست بھیجنے کی طرف جا سکتا ہے۔
صرف دوسرا کنفیگریشن کا سوال ہے۔ باقی دو ڈیزائن کے سوال ہیں کہ مصنوعہ کتنا اندازہ لگانے کو تیار ہے۔
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
سابقہ کب بہتر جواب ہے
مستحکم نجی ذیلی نیٹ ورک کے لیے واضح سابقہ زیادہ واضح، تیز اور جانچنے میں آسان ہوتا ہے۔ یہ حل کنندہ کی خرابی بھی برداشت کرتا ہے، کیونکہ کچھ حل کرنے کی ضرورت نہیں ہوتی۔ ڈومین قاعدہ اس وقت استعمال کریں جب سروس ہوسٹ کی گئی ہو، جب ایڈریسز گردش کر رہے ہوں، یا جب آپ واقعی منزل کا مجموعہ شمار نہ کر سکیں۔ صرف اس لیے استعمال نہ کریں کہ ہوسٹ نام وہی چیز ہے جو آپ کو اتفاقاً معلوم ہے۔
اندازہ لگائی گئی جامد فہرست دونوں میں بدترین ہے: دیکھنے میں برقرار رکھی گئی لگتی ہے، اور جس دن فراہم کنندہ ہوسٹ شامل کرتا ہے اس دن خاموشی سے ٹریفک چھوڑ دیتی ہے۔
نئی درخواست سے تصدیق کریں
عام دوبارہ کنکشن کے بعد ٹھنڈی درخواست سے جانچیں، کیونکہ کیش شدہ صفحہ کبھی قاعدے کو نہ چھو سکے۔ نام حل کریں، پھر دیکھیں کہ کنکشن دراصل کہاں گیا۔ dig +short app.example.com موجودہ ایڈریس مجموعہ دیتا ہے، اور کلائنٹ کی کنکشن فہرست بتاتی ہے کہ کون سا انٹرفیس بہاؤ لے گیا۔
مصنوعہ جو تازہ کاری وقفہ دستاویز کرتی ہے اس کے بعد دہرائیں۔ اگر ایڈریس مجموعہ سرک جائے اور قاعدہ اس کی پیروی نہ کرے، تو آپ نے اصل رویہ ڈھونڈ لیا۔
حل کنندہ کی پالیسی بھی الگ رکھیں۔ ڈومین قاعدے کو درست نام ڈیٹا درکار ہے، لیکن یہ خود فیصلہ نہیں کرتا کہ کون سا حل کنندہ استفسار کا جواب دیتا ہے۔