کیا آپ کا VPN DNS کو خفیہ کرتا ہے، یا صرف اگلا ہاپ؟

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

کنفیگریشن فائل کو چھونے سے پہلے ہر مرحلے پر لکھیں کہ استفسار کس کو ملتا ہے۔

دو ترتیبیں سیٹنگز صفحے پر ایک جیسی دکھتی ہیں

پہلی ترتیب میں ڈیوائس خود DNS over TLS چلاتی ہے، اور ٹنل صرف وہ کنکشن آپ کے منتخب کردہ ریزالور تک لے جاتی ہے۔ TLS سیشن ریزالور پر ختم ہوتا ہے، یعنی ریزالور استفسار دیکھتا ہے اور VPN کا اخراج وہ خفیہ متن دیکھتا ہے جو وہ پڑھ نہیں سکتا۔ دوسری ترتیب میں ڈیوائس عام DNS کو ٹنل کے ذریعے VPN ہوسٹ پر فارورڈر تک بھیجتی ہے، اور وہ فارورڈر بالائی ریزالور سے اپنا خفیہ کنکشن کھولتا ہے۔ خصوصیات کی فہرست میں دونوں "VPN کے ساتھ خفیہ DNS" جیسے دکھتے ہیں، مگر پڑھا جا سکنے والا استفسار مختلف عمارتوں میں رکھتے ہیں۔

فرق فلسفیانہ نہیں، ناپا جا سکتا ہے۔ کلائنٹ یا سرور پر TLS سیشن تلاش کریں، اور آپ کو معلوم ہو جائے گا کہ واقعی کون سی ترتیب ہے۔

بدلنے سے پہلے ریزالور زنجیر کا نقشہ بنائیں

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

پھر پوچھیں کہ کلائنٹ کس جزو کو استعمال کرنے کے لیے ترتیب دیا گیا ہے۔ VPN پروفائل کا دیا ہوا DNS پتہ بتاتا ہے کہ استفسار کہاں جاتے ہیں، یہ نہیں کہ کون سا عمل جواب دیتا ہے۔

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

تصدیق کریں کہ کون سا ہاپ خفیہ ہے

کلائنٹ سے شروع کریں اور تصدیق کریں کہ آیا اس کے پاس پورٹ 853 کے لیے TLS سیشن ہے۔ وہ استفسار جو پورٹ 53 کے ذریعے درست حل ہوتا ہے، خفیہ کاری کے بارے میں کچھ ثابت نہیں کرتا۔

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

پھر VPN ہوسٹ پر جائیں اور وہ بیرونی خفیہ کنکشن تلاش کریں جو فارورڈر نے کھولا۔ سوکٹ جدول بتاتا ہے کہ بالائی TLS سیشن موجود ہے یا نہیں، اور کون سا عمل اس کا مالک ہے:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

اگر کلائنٹ TLS سیشن دکھائے اور سرور کچھ نہ دکھائے تو آپ پہلی ترتیب میں ہیں اور سرور IP سطح پر بھیجے جانے والے استفسار نہیں پڑھ سکتا۔ اگر سرور TLS سیشن دکھائے اور کلائنٹ ٹنل کے اندر عام پورٹ 53 ٹریفک دکھائے تو آپ دوسری ترتیب میں ہیں: اگلا ہاپ محفوظ ہے، اور فارورڈر اب بھی ہر وہ نام پڑھتا ہے جو ڈیوائس پوچھتی ہے۔ وہ دوسرا نتیجہ ناکامی نہیں، مگر اسے سرے سے سرے تک خفیہ کاری کہنا غلط ہے۔

مالک اور ناکامی کا رویہ ریکارڈ کریں

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

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

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