کیا VPN نے میرا DNS بدل دیا؟ پہلے اور بعد کا موازنہ کریں
ایک پروفائل آپ کی استعلامات کو جان بوجھ کر منتقل کر سکتا ہے۔ VPN جڑنے سے پہلے اور بعد میں ریزارور کی پالیسی اور اصل جواب کا موازنہ کریں، ایک متغیر کو مستقل رکھتے ہوئے۔
آپ ٹنل جوڑتے ہیں، نجی ڈیش بورڈ کھولتے ہیں، اور نام کسی ایسے پتے پر حل ہوتا ہے جو آپ نے کبھی نہیں دیکھا۔ یا اس کے برعکس ہوتا ہے: براؤزر کام کرتا رہتا ہے جبکہ کمانڈ لائن کا آلہ اچانک کچھ بھی حل نہیں کرتا۔ دونوں نتائج ایک ہی تبدیلی سے آتے ہیں، اور لوگ عام طور پر اسے VPN کے بارے میں ایک جملے سے سمجھاتے ہیں کہ "یہ اپنا DNS استعمال کرتا ہے"، جو خرابی دور کرنے یا تصدیق کے لیے کافی درست نہیں ہے۔ اس جملے میں دو سوال پوشیدہ ہیں: یہ پروفائل کون سی استعلامات سنبھالے، اور کیا آپ کے آلے نے وہ واقعی اسی ریزارور کو بھیجیں جو اسے دیا گیا تھا؟ انہیں الگ رکھنا ہی پورا طریقہ ہے، کیونکہ انہیں ملانے والا امتحان دونوں سمتوں میں پراعتماد غلط جواب دیتا ہے۔
پروفائل آخر ریزارور کیوں فراہم کرتا ہے
ٹنل کے اندر، دور کے سرے کے پیچھے موجود نام عام طور پر ایسے پتوں پر حل ہوتے ہیں جو صرف اسی نیٹ ورک میں موجود ہیں۔ corp.internal جیسے نجی زون کے پاس کوئی عوامی تفویض نہیں ہے، اس لیے اسے جواب دینے والا ریزارور ٹنل کے اندر سے قابل رسائی ہونا چاہیے۔ یہی طریقہ کار دوسرے مقصد کے لیے بھی کام آتا ہے: جب استعلامات بصورت دیگر آپ کے ISP سے باہر جاتیں، تو دور کے سرے کا ریزارور استعلام کو خفیہ راستے کے اندر رکھتا ہے۔ اسی لیے DNS سرور کا پتہ کنکشن کی پالیسی کے حصے کے طور پر آتا ہے، نہ کہ ایسی عالمی ترتیب کے طور پر جو آپ نے آلے کے لیے ایک بار منتخب کی ہو۔
پتہ بذات خود کچھ طے نہیں کرتا۔ ریزارور صرف تب جواب دے سکتا ہے جب وہاں تک کوئی راستہ ہو، اور سب سے عام خرابی وہ ریزارور ہے جو صرف اس وقت قابل رسائی ہو جب ٹنل قائم ہو۔ جب ٹنل گر جائے اور پالیسی رہے، تو استعلامات بغیر راستے والے پتے کی طرف جاتی ہیں، اور علامت صاف غلطی نہیں بلکہ وقت کا ختم ہونا ہے۔ اگلا امتحانی نتیجہ پڑھتے وقت یہ فرق اہم ہے، کیونکہ وقت کا ختم ہونا لوگوں کو ایسی ٹرانسپورٹ ترتیبات کی طرف بھیجتا ہے جو کبھی شامل نہیں تھیں۔
جوابات کا موازنہ کرنے سے پہلے دو ڈیزائنوں کا موازنہ کریں
مکمل ٹنل اور تقسیم شدہ DNS الٹ توقعات پیدا کرتے ہیں، اور دونوں میں سے کوئی خرابی نہیں ہے۔ مکمل ٹنل کے تحت ہر استعلام فراہم کنندہ یا کارپوریٹ ریزارور کی طرف جا سکتی ہے، اس لیے جڑنے کے بعد عوامی ناموں کا مختلف جواب دینا متوقع ہے۔ تقسیم شدہ DNS کے تحت صرف فہرست شدہ ڈومین نجی ریزارور کی طرف جاتے ہیں جبکہ باقی سب مقامی رہتا ہے؛ Windows میں ڈومین فہرست Name Resolution Policy Table میں، macOS میں DNS ترتیبات کے مماثل ڈومینوں میں، اور systemd-resolved ہوسٹ پر ہر لنک کے روٹنگ ڈومینوں میں رہتی ہے۔
یہی موازنہ پہلے کرنا چاہیے، کیونکہ یہ طے کرتا ہے کہ کس چیز کو خرابی سمجھا جائے۔ تقسیم شدہ DNS کے ساتھ، نیا ریزارور سے جواب دینے والا عوامی نام ہی جانچ کے قابل ہے، جبکہ درست جواب دینے والا اندرونی نام یہ ہے کہ نظام اپنا کام کر رہا ہے۔ مکمل ٹنل کے ساتھ، بے قاعدگی وہ عوامی نام ہے جو اب بھی آپ کے ISP ریزارور سے جواب دیتا ہے۔ Microsoft کی VPN ناموں کے حل کی دستاویز ان قواعد کی Windows ترتیب بیان کرتی ہے، بشمول یہ کہ مماثل پالیسی اندراج ایڈاپٹر کے اپنے سرورز سے پہلے کیسے دیکھا جاتا ہے۔
کمرے میں تیسرا ریزارور بھی ہے جسے بھولنا آسان ہے۔ براؤزر کا محفوظ DNS خود نام حل کرتا ہے اور ٹنل کے آپریٹنگ سسٹم کی پالیسی بدلنے کے بعد بھی جواب دیتا رہ سکتا ہے، اس لیے لوڈ ہونے والا صفحہ ثابت کرتا ہے کہ براؤزر کا ریزارور کام کر گیا، یہ نہیں کہ پروفائل لاگو ہوا۔ اگر آپ صرف وہی موازنہ کریں جو براؤزر دکھاتا ہے، تو آدھے وقت آپ غلط تہہ جانچ رہے ہیں۔
صرف ایک متغیر کے ساتھ بنیادی لکیر درج کریں
ٹنل بدلیں۔ اسی مرحلے میں نام، آلہ یا تلاش کی لاحقہ بھی نہ بدلیں۔ ایسا نام منتخب کریں جس کے بارے میں پوچھنے کی آپ کو اجازت ہو، نوٹ کریں کہ کون سی ایپلیکیشن استعمال کی، اور یا واپس آیا پتہ یا درست غلطی لکھیں۔ Windows میں Get-DnsClientServerAddress -AddressFamily IPv4 ہر ایڈاپٹر کے سرورز چھاپتا ہے اور Get-DnsClientNrptPolicy پالیسی اندراجات چھاپتا ہے؛ systemd-resolved والے Linux میں resolvectl status ہر لنک کے DNS سرورز اور روٹنگ ڈومین دکھاتا ہے؛ macOS میں scutil --dns وہ ریزارور ترتیب چھاپتا ہے جس پر نظام واقعی عمل کرے گا۔
پھر کلائنٹ کے عام کنٹرولز سے جڑیں اور بالکل وہی کمانڈز دہرائیں۔ پہلا آؤٹ پٹ یاد رکھنے کی بجائے محفوظ کریں، کیونکہ موازنہ ہی پورا مقصد ہے اور کیش خالی کرنے کے بعد لی گئی دوسری قراءت پہلے ہی ایک اور پیمائش ہے۔ اگر بنیادی لکیر براؤزر کو سامنے رکھ کر لی گئی تھی اور جڑنے کے بعد کی کارروائی ٹرمینل میں ہوتی ہے، تو آپ دو ریزارورز کا موازنہ کر رہے ہیں، ایک ریزارور کی دو حالتوں کا نہیں۔
واضح استعلام اور ایپلیکیشن کی تلاش مختلف امتحان ہیں
کسی ایک مخصوص سرور سے nslookup name 10.20.0.1 یا dig @10.20.0.1 name کے ذریعے پوچھنا صرف ایک بات ثابت کرتا ہے: کہ آپ کا نامزد کردہ سرور تب جواب دیتا ہے جب آپ اس تک پہنچ سکیں۔ یہ انتخاب کی منطق کو مکمل طور پر نظرانداز کرتا ہے، اس لیے یہ نہیں بتا سکتا کہ نظام اس نام کے لیے وہی سرور منتخب کرتا یا نہیں۔ اسے یہ جانچنے کے لیے استعمال کریں کہ مقرر کردہ ریزارور قابل رسائی ہے یا نہیں، اور پالیسی جانچنے کے لیے استعمال نہ کریں۔
مقامی ریزارور کے ذریعے تلاش انتخاب کو واقعی بروئے کار لاتی ہے۔ resolvectl query name وہی روٹنگ ڈومین قواعد طے کرتا ہے اور بتاتا ہے کہ کس پروٹوکول نے جواب دیا، Windows میں Resolve-DnsName پالیسی جدول اور کلائنٹ کیش سے گزرتا ہے، اور scutil --dns وہ ترتیب دکھاتا ہے جس پر تلاش عمل کرے گی۔ دونوں قسمیں چلائیں اور انہیں اپنے نوٹس کے الگ کالموں میں رکھیں۔ کامیاب واضح استعلام کے ساتھ ناکام ایپلیکیشن تلاش روٹنگ یا انتخاب کا مسئلہ ہے، کام کرنے سے انکار کرنے والا ریزارور نہیں۔
کیش آپ اور جواب کے درمیان کھڑا ہے۔ آپریٹنگ سسٹم، مقامی stub ریزارور، براؤزر اور منفی کیش سب نتائج رکھتے ہیں، اس لیے تلاش ایک بھی پیکٹ آلے سے باہر نکلنے کے بغیر کامیاب ہو سکتی ہے۔ کچھ بھی خالی کرنے سے پہلے نتیجہ درج کریں: ipconfig /flushdns، resolvectl flush-caches یا macOS میں sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder۔ اس مرحلے پر وسیع نیٹ ورک ری سیٹ چھوڑ دیں، کیونکہ یہ وہ شواہد تباہ کرتا ہے جو آپ ابھی جمع کر رہے ہیں۔
اس فرق کا مطلب کیا ہے
آپ نے درج کی گئی دو سطریں موازنہ کریں اور ایک بھی ترتیب چھونے سے پہلے تبدیلی کی درجہ بندی کریں۔
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
ایک سطر خاص زور کی حقدار ہے۔ حل ہونے والا نام کام کرتی ہوئی خدمت نہیں ہے، اور DNS کی کامیابی صرف یہ کہتی ہے کہ پتہ مل گیا۔ یہ فارورڈنگ، فائر وال قواعد یا اس بارے میں کچھ نہیں کہتی کہ آپ کا اکاؤنٹ یہ خدمت استعمال کر سکتا ہے یا نہیں، اس لیے یہ فرض کرنے کی بجائے کہ خرابی خود بخود چلی گئی، اصل ایپلیکیشن جانچ کر ختم کریں۔
بنیادی لکیر بحال کریں اور تصدیق کریں
عمل کو مارنے کی بجائے کلائنٹ کے اپنے کنٹرولز سے منقطع کریں، پھر وہی تین کمانڈز دوبارہ پڑھیں۔ ہر لنک کے سرورز، پالیسی اندراجات اور آپ کے ٹیسٹ نام کا جواب پہلے لکھی گئی بنیادی لکیر پر واپس آنا چاہیے۔ صاف منقطع ہونے کے بعد باقی رہنے والا پالیسی اندراج ایک حقیقی نقص ہے جسے درج کرنا چاہیے، اور اسی لیے تیار شدہ ریزارور فائل میں ہاتھ سے ترمیم کرنا بری عادت ہے: فائل دوبارہ لکھی جاتی ہے اور ترمیم غائب ہو جاتی ہے، یا ترمیم باقی رہتی ہے اور ایسے ریزارور کو پن کر دیتی ہے جس کا اب کوئی راستہ نہیں۔
اس فہرست کو ایک بار، ترتیب سے کریں۔ کسی بھی نتیجے کا فیصلہ کرنے سے پہلے طے کریں کہ پروفائل کون سا ڈیزائن نافذ کرتا ہے۔ دونوں دوڑوں میں نام، آلہ اور لاحقہ مستقل رکھیں۔ واضح استعلام کو ایپلیکیشن تلاش سے الگ رکھیں۔ صرف جواب نہیں، مؤثر پالیسی پڑھیں۔ موازنہ لکھنے کے بعد کیش آخر میں خالی کریں۔ اصل ایپلیکیشن سے تصدیق کریں، پھر ایک بار دوبارہ شروع کریں اور یقینی بنائیں کہ منقطع حالت اب بھی صاف ہے۔