DNS کو صرف اپنے VPN حل کنندہ کے ذریعے جانے دیں: مرحلہ وار رہنمائی
براؤزر سے جواب تک ایک نام کی تلاش کا پیچھا کریں۔ دیکھیں حل کنندہ کہاں منتخب ہوتا ہے، فائر وال کہاں اسے نافذ کرتا ہے اور پورٹ 53 کا اصول کبھی کیا نہیں ڈھکتا۔
جس لمحے آپ نام لکھتے ہیں اسی لمحے سے ایک نام کی تلاش کا پیچھا کریں۔ براؤزر آپریٹنگ سسٹم سے پوچھتا ہے، آپریٹنگ سسٹم اس حل کنندہ سے پوچھتا ہے جو اس کی پالیسی منتخب کرتی ہے، اور استفسار کسی انٹرفیس سے کسی ترسیل کے ساتھ ڈیوائس سے باہر جاتا ہے۔ آپ کا VPN ڈیزائن کہتا ہے کہ جواب کسی مخصوص حل کنندہ سے کسی مخصوص راستے پر آنا چاہیے۔ ان دونوں باتوں کے درمیان فرق ہی وہ ہے جو آپ ترتیب دیتے ہیں اور پھر نافذ کرتے ہیں۔
مرحلہ 1: حل کنندہ اور راستے کا نام رکھیں
فائر وال کو چھونے سے پہلے تین چیزیں لکھیں: حل کنندہ کا پتہ، وہ پروٹوکول اور پورٹ جن کی آپ توقع کرتے ہیں، اور وہ انٹرفیس جس سے استفسار باہر جانا چاہیے۔ اس فہرست کے بغیر اصول ٹریفک کے بارے میں ایک اندازہ ہے، کسی فیصلے کا نفاذ نہیں۔ VPN ایپلیکیشن کا ڈیٹا لے جا سکتا ہے جبکہ DNS الگ ترتیب پر چلے، اور یہ بذات خود غلطی نہیں۔ یہ اسی وقت ہوتا ہے جب کسی نے کلائنٹ کو کچھ اور نہ بتایا ہو۔
راستے کا واضح نام رکھنا ڈیزائن اور حادثے کے درمیان فرق ہے۔ یہ آپ کو بعد میں جانچنے کے لیے کچھ دیتا ہے، کیونکہ ہر مشاہدے کا موازنہ تحریری توقع سے کیا جا سکتا ہے۔ وہ فہرست تبدیلی ٹکٹ میں رکھیں، کسی کے سر میں نہیں۔
مرحلہ 2: پالیسی وہیں رکھیں جہاں وہ واقعی رہتی ہے
حل کنندہ کا انتخاب کلائنٹ کا معاملہ ہے: آپریٹنگ سسٹم کی نیٹ ورک ترتیب، VPN کلائنٹ کی اپنی سیٹنگز، یا زیرِ انتظام براؤزر پالیسی۔ پہلے وہیں رکھیں، اس طریقے سے جس کی پلیٹ فارم حمایت کرتا ہے، کیونکہ فائر وال کلائنٹ کو ایسا حل کنندہ چننے پر مجبور نہیں کر سکتا جس کے بارے میں اسے کبھی بتایا ہی نہ گیا ہو۔ تقسیم شدہ ٹنل والے کلائنٹ پر واضح کہیں کہ کون سے ڈومین اندرونی حل کنندہ کو جاتے ہیں۔ زیرِ انتظام گروپ میں DoH کے لیے براؤزر پالیسی ہی اکثر واحد ذریعہ ہوتی ہے، کیونکہ براؤزر سسٹم سیٹنگ سے آزاد ہو کر اپنا خفیہ کردہ حل کنندہ چن سکتا ہے۔
یہ چھوڑ کر سیدھا فائر وال پر جائیں تو آپ کو صحیح حل کنندہ کی اجازت دینے والا اصول اور ایسا کلائنٹ ملے گا جو اسے کبھی استعمال نہیں کرتا۔ اصول درست لگتا ہے اور حل کنندہ کے لاگ خالی رہتے ہیں، جو خرابی تلاش کرنے میں الجھانے والا جوڑ ہے۔ پہلے انتخاب ترتیب دیں، پھر اسے نافذ کریں۔
مرحلہ 3: راستے کو تنگ دائرے میں نافذ کریں
اب اجازت یافتہ راستے کے لیے نیٹ ورک کی اجازت شامل کریں: حل کنندہ کا پتہ، پروٹوکول اور پورٹ، اور وہ انٹرفیس جس سے اسے باہر جانا ہے۔ اصول کو اسی حل کنندہ تک محدود رکھیں بجائے یہ کہ تمام باہر جانے والے DNS کی اجازت دیں۔ نیچے دیے گئے تین راستے وہ ہیں جو جدید کلائنٹ لے سکتا ہے، اور پورٹ 53 کا اصول صرف پہلے کو ڈھکتا ہے۔
| Path | Port | Who controls it |
|---|---|---|
| Classic DNS | UDP and TCP 53 | System resolver settings |
| DNS over TLS | TCP 853 | Resolver or stub configuration |
| DNS over HTTPS | TCP 443 | Browser or application policy |
DoH اور DoT کو روکنا جائز ہے؛ یہ سمجھنا کہ پورٹ 53 کے اصول نے انہیں پہلے ہی روک دیا ہے، جائز نہیں۔ DoH استعمال کرنے والا براؤزر نام ایسے راستے سے حل کرتا ہے جو آپ کے اصول نے کبھی بیان نہیں کیا، اور اپنا حل کنندہ ساتھ لانے والی ایپلیکیشن بھی ایسا ہی کرتی ہے۔ ہر وہ راستہ لکھیں جس کی اجازت دینی ہے اور ہر وہ جسے مسترد کرنا ہے۔ جو اصول کسی راستے کا نام نہیں لیتا، اس نے اس کے بارے میں کچھ فیصلہ نہیں کیا۔
مرحلہ 4: نجی اور عوامی ناموں کا پیچھا کریں
تقسیم شدہ DNS جان بوجھ کر صرف نجی نام کی جگہیں اندرونی حل کنندہ کو بھیجتا ہے جبکہ عوامی نام کہیں اور جاتے ہیں، اس لیے ڈیزائن میں ایک سے زیادہ حل کنندہ ہونا لیک نہیں۔ لیک وہ استفسار ہے جو آپ کے حل کنندہ کو جانا چاہیے تھا اور کہیں اور پہنچ جاتا ہے، یا کوئی ناقابلِ رسائی مطلوبہ راستہ جو کلائنٹ کو خاموشی سے پیچھے ہٹا دیتا ہے۔ یہی دو صورتیں تلاش کرنی ہیں۔ مطلوبہ پالیسی کے تحت ایک اندرونی اور ایک عوامی نام کا پیچھا کریں اور لکھیں کہ کس حل کنندہ نے کس کا جواب دیا۔
آپ کے حل کنندہ کی رپورٹ دینے والی جانچ سائٹ ایک اشارہ ہے، ثبوت نہیں، کیونکہ وہ صرف وہی استفسار دیکھتی ہے جو اس تک پہنچے۔ جب جاننا ہو کہ استفسار نے واقعی کون سا راستہ لیا، تو اسے کلائنٹ کی طرف پکڑیں، پھر دونوں مشاہدات کا موازنہ کریں۔ جب وہ نہ ملیں تو آپ نے ایسی واپسی پائی ہے جسے کسی نے درج نہیں کیا۔
اگر حل کنندہ کا پتہ درست ہے مگر ناقابلِ رسائی ہے، تو مسئلہ پالیسی میں نہیں، روٹنگ یا فلٹرنگ میں ہے۔ استفسار کا پیچھا اس پتے تک کریں اور کوئی بھی حل کنندہ سیٹنگ بدلنے سے پہلے تصدیق کریں کہ جواب متوقع انٹرفیس پر واپس آتا ہے۔
مرحلہ 5: واپسی کا راستہ کھلا رکھیں
گیٹ وے پر DNS تک رسائی سخت کرنے سے پہلے ایسا بحالی طریقہ تصدیق کریں جو نام حل کرنے پر منحصر نہ ہو۔ خراب حل کنندہ ہر مرمت کے اوزار تک رسائی مشکل بناتا ہے، بشمول وہ جن سے آپ تبدیلی واپس لیں گے۔ نئی پالیسی ثابت ہونے تک مقامی کنسول یا بینڈ سے باہر کا راستہ کھلا رکھیں۔ اسے صرف اس وقت ہٹائیں جب پالیسی نے دوبارہ رابطہ برداشت کر لیا ہو۔
دوبارہ رابطے یا براؤزر پالیسی کی تازہ کاری کے بعد موثر حالت دوبارہ دیکھیں، کیونکہ دونوں آپ کے اصول کو بدلے بغیر حل کنندہ بدل سکتے ہیں۔ تقاضا یہ ہے کہ استفسارات کے لیے معلوم وصول کنندہ اور محفوظ راستہ ہو، نہ کہ ایک اسکرین شاٹ پر تسلی دینے والا حل کنندہ لیبل۔ RFC 8484 DNS over HTTPS تصریح اس خفیہ راستے کا حوالہ ہے جو آپ کا پورٹ اصول نہیں دیکھتا۔