نجی DNS نام VPN کلائنٹس پر کیوں ناکام ہوتے ہیں اور کہاں جانچنا چاہیے

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

کسی بھی پروفائل میں ترمیم سے پہلے تصدیق کریں کہ کلائنٹ نام کے ساتھ کیا کرتا ہے۔ Linux میں resolvectl query files.corp.example دکھاتا ہے کہ کون سی رابطہ اور کون سا حل کنندہ جواب بنا۔ Windows میں Resolve-DnsName files.corp.example وہ سرور دکھاتا ہے جس نے جواب دیا اور وہ پتہ جو اس نے واپس کیا۔

کچھ بدلنے سے پہلے جواب پڑھیں

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

یہ تقسیم بثلاث گھنٹہ بھر کا اندازہ بچاتی ہے۔ یہ یہ بھی بتاتی ہے کہ VPN کو چھونا ہے یا نہیں: وہ نام جو درست نجی پتے پر حل ہو وہ حل کنندہ کا راستہ پہلے ہی ثابت کر چکا ہے، لہٰذا باقی کام ڈیٹا کے راستے پر ہے۔

حل کنندہ کو سرنگ کے اندر سے تقسیم کریں

کلائنٹ دو گروہوں میں بٹتے ہیں۔ ایک کو سرور رابطہ قائم ہونے کے دوران حل کنندہ دے سکتا ہے؛ دوسرا ترتیب کو مقامی فائل میں رکھتا ہے جسے کوئی گیٹ وے دور سے بدل نہیں سکتا۔

OpenVPN پہلے گروہ میں ہے۔ سرور پر push "dhcp-option DNS 10.8.0.53" اور push "dhcp-option DOMAIN corp.example" کنٹرول چینل سے اترتے ہیں، مگر صرف اسی صورت میں جب کلائنٹ کی ترتیب میں pull اب بھی فعال ہو۔ ہاتھ سے ترمیم شدہ کلائنٹ جو pull-filter ignore "dhcp-option" اٹھائے ہوئے ہے وہ انہیں کبھی نہیں دیکھے گا، اور یہی ایک سطر حیران کن طور پر بہت سے ایسے واقعات کی وضاحت کرتی ہے کہ ”سرور اسے دھکیلتا ہے مگر میرا لیپ ٹاپ مانتا نہیں“۔

WireGuard دوسرے گروہ میں ہے، کیونکہ پروٹوکول میں اختیارات کی کوئی گفت و شنید ہی نہیں۔ حل کنندہ اور تلاش کا ڈومین کلائنٹ کے اپنے [Interface] بلاک میں DNS = 10.8.0.53, corp.example کی صورت میں جاتے ہیں۔ wg-quick اسے resolvconf یا systemd-resolved کے ذریعے لاگو کرتا ہے، اور Windows پر سرکاری کلائنٹ NRPT کے وہ قواعد نصب کرتا ہے جو صرف اسی وقت موجود ہوتے ہیں جب سرنگ کھڑی ہو: Get-DnsClientNrptPolicy انہیں گنواتا ہے، جو اسے یہ دیکھنے کا تیز طریقہ بناتا ہے کہ کلائنٹ نے آپ کی فائل کبھی لاگو کی یا نہیں۔

IPsec/IKEv2 درمیان میں ہے۔ strongSwan کا attr پلگ ان تالاب سے نکالا گیا DNS سرور واپس دے سکتا ہے، اور Windows کلائنٹ عام طور پر اسے قبول کر لیتا ہے، مگر وہ پروفائل جو اپنا نام سرور جما دیتا ہے گیٹ وے کی ہر پیشکش پر بھاری پڑتا ہے۔ Linux کلائنٹ پر مساوی دستی قدم resolvectl dns wg0 10.8.0.53 اور پھر resolvectl domain wg0 '~corp.example' ہے؛ دونوں انٹرفیس کے ساتھ غائب ہو جاتے ہیں، جو سرنگ تک محدود ترتیب کے لیے عین وہی ہے جو آپ چاہتے ہیں۔

ہر استفسار نگلنے کے بجائے لاحقہ محدود کریں

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

اندر صرف نجی لاحقہ بھیجیں۔ systemd-resolved میں وہ ڈومین جو ~ سے شروع ہو صرف راست گزاری کے لیے ہے، لہٰذا ~corp.example کا مطلب ہے کہ اس لاحقے کے تحت استفسارات اسی رابطے کے سرورز کو جاتے ہیں جبکہ باقی سب جسمانی نیٹ ورک استعمال کرتے رہتے ہیں۔ Windows یہی کام نام کی فضا تک محدود NRPT قواعد سے کرتا ہے، اور macOS /etc/resolver/ کے تحت اضافی حل کنندہ فائل سے۔

ملٹی کاسٹ نام اپنا جواب مستحق ہیں۔ .local نام بناوٹ کے لحاظ سے link-local ہیں (RFC 6762) اور نقطہ بہ نقطہ tun انٹرفیس وہ ملٹی کاسٹ گروہ نہیں اٹھاتا، اس لیے عوامی حل کنندہ شامل کرنا انہیں شائع نہیں کرے گا اور اندرونی unicast حل کنندہ سے ان کے بارے پوچھنے پر NXDOMAIN واپس آتا ہے۔ avahi جیسا منعکس کنندہ منعکس حالت میں دو قطعے جوڑ سکتا ہے، مگر یہ سرور کی طرف کا فیصلہ ہے جو کوئی کلائنٹ طلب نہیں کر سکتا۔ اگر پرنٹر یا NAS نام سے قابل رسائی ہونا ضروری ہو، تو اس کے بجائے اپنے زون میں اسے A ریکارڈ دیں۔

ثابت کریں کہ جواب واپس آ سکتا ہے

ناقابل رسائی پتے کی طرف اشارہ کرنے والا درست جواب بالکل حل کنندہ کے مسئلے جیسا لگتا ہے جب تک آپ راستہ نہ جانچیں۔ کرنل سے پوچھیں کہ جواب کہاں جائے گا: ip route get 10.20.5.20 انٹرفیس اور زیادہ مفید بات یہ کہ وہ ماخذ پتہ بتاتا ہے جو وہ استعمال کرے گا۔

خود حل کنندہ کے پتے پر نظر رکھیں۔ وہ کلائنٹ جس کے پاس DNS = 10.8.0.53 کے ساتھ AllowedIPs = 10.20.0.0/16 ہے اپنے استفسارات جسمانی NIC سے باہر بھیجتا ہے، جہاں وہ خاموشی سے مر جاتے ہیں، کیونکہ حل کنندہ کسی ایسے سابقے کے اندر نہیں جو سرنگ کا دعویٰ ہے۔ یہی عدم مطابقت اس پورے میدان میں سب سے عام واحد سببی خرابی ہے، اور یہ تب تک نظر نہیں آتی جب تک آپ DNS ترتیب کا اجازت شدہ سابقوں سے سطر بہ سطر موازنہ نہ کریں۔

اوور لیپنگ حدود الٹی خرابی پیدا کرتی ہیں۔ جواب درست ہے، راستہ موجود ہے، اور یہ غلط میزبان کی طرف اشارہ کرتا ہے، کیونکہ گھر پر 192.168.0.0/24 اسی حد تک سرنگ کے راستے سے زیادہ مخصوص ہے۔ ایک طرف دوبارہ نمبر دیں یا تنگ تر راستہ دھکیلیں، پھر خدمت کے میزبان کا فائر وال اور واپسی راستہ تصدیق کریں؛ strongSwan کے آگے بھیجنے بارے نوٹس اس راستے کے sysctl پہلو کو محیط ہیں۔

سرٹیفکیٹ ایک الگ شناختی جانچ ہے جس کا الزام لوگ DNS پر لگاتے ہیں۔ اگر براؤزر حل کی خرابی کے بجائے نام کی عدم مطابقت بتائے، تو تلاش پہلے ہی کام کر چکی ہے اور سرٹیفکیٹ میں SAN ہی وہ چیز ہے جسے ٹھیک کرنا ہے۔ HTTPS کو نام پر آزمائیں، کبھی ننگے IP پر نہیں۔

گیٹ وے سے نہیں، کلائنٹ سے دوبارہ جانچیں

اُس ایپلیکیشن کے اندر جانچیں جس کی صارف شکایت کرتا ہے، کیونکہ کمانڈ لائن سے تلاش یہ ثابت نہیں کرتی کہ براؤزر بھی وہی راستہ لیتا ہے۔ Chrome کا محفوظ DNS اور Firefox کا network.trr.mode نظام کے حل کنندہ کو مکمل طور پر بائی پاس کر سکتے ہیں، اور جب ایسا کرتے ہیں تو نجی نام یا ناکام ہوتا ہے یا عوامی حل کنندہ کی طرف رس جاتا ہے۔ resolvectl query کا ہاتھ سے چلائے گئے dig @10.8.0.53 files.corp.example سے موازنہ بتاتا ہے کہ دونوں میں سے کیا ہوا۔

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

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