VPN جڑنے سے پہلے ہاٹ اسپاٹ DNS کو کیوں موڑ دیتا ہے؟
ہاٹ اسپاٹ اپنے نیٹ ورک پر تلاشیں دوبارہ لکھتا ہے، اور میزبان نام کا اختتامی نقطہ کسی بھی سرنگ سے پہلے حل ہو جاتا ہے۔ ٹریک کریں کہ ہر سوال کا جواب کس حل کنندہ نے دیا۔
ہوٹل کے نیٹ ورک سے جڑنا آپ کے سامنے مختلف لمحوں میں دو DNS فیصلے رکھتا ہے: وہ تلاشیں جو آلہ سائن اِن کرتے وقت کرتا ہے، اور وہ تلاشیں جو سرنگ کھڑی ہونے کے بعد کی جاتی ہیں۔ ہاٹ اسپاٹ اپنے کنٹرول والے نیٹ ورک کے ذریعے پہلی کو متاثر کر سکتا ہے۔ دوسری کلائنٹ کی اپنی پالیسی پر منحصر ہے، جو الگ جانچنے کی چیز ہے۔
رابطے کو ترتیب سے دیکھیں، پہلی DHCP لیز سے اُس سوال تک جس نے نجی نام حل کیا۔ پھر سپورٹ ٹکٹ میں یکساں نظر آنے والی دو ناکامیاں صاف طور پر الگ ہو جاتی ہیں: ایک سرنگ سے پہلے ہوئی، دوسری اُس کے اندر۔
ہاٹ اسپاٹ کیا چھو سکتا ہے اور کیا نہیں
رسائی نیٹ ورک DHCP میں حل کنندہ کا پتہ دیتا ہے اور اُس پتے کی طرف پورٹ 53 کو روک سکتا ہے۔ یہ ہر غیر محفوظ تلاش کو پورٹل پتے یا بلاک صفحے سے جواب دینے کے لیے کافی ہے۔ یہ ایسے VPN کلائنٹ کو توڑنے کے لیے بھی کافی ہے جس کا اختتامی نقطہ میزبان نام کے طور پر لکھا گیا ہو۔
ہاٹ اسپاٹ جو نہیں کر سکتا وہ یہ ہے کہ قائم شدہ سرنگ کے اندر سوال گزر جانے کے بعد اُسے پڑھے یا دوبارہ لکھے، بشرطیکہ سرنگ واقعی اُسے لے جا رہی ہو۔ روکنا سادہ متن میں سوال دیکھنے پر منحصر ہے۔
سوالات بہرحال سرنگ سے باہر جاتے ہیں اُن وجوہات کی بنا پر جن کا ہاٹ اسپاٹ سے تعلق نہیں: براؤزر کی محفوظ DNS ترتیب، ایک split-DNS قاعدہ جو کارپوریٹ لاحقہ مقامی حل کنندہ پر رکھتا ہے، یا ایسا کلائنٹ جو DNS کو سرنگ سے خارج کرنے کے لیے ترتیب دیا گیا ہو۔ ہر ایک کلائنٹ کی طرف کا انتخاب ہے، اور باہر سے دیکھنے پر ہر ایک ہاٹ اسپاٹ کی مداخلت جیسا لگتا ہے۔
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
پہلی تلاش سرنگ بننے سے پہلے ہوتی ہے
میزبان نام ملنے والے کلائنٹ کو پہلے اُسے حل کرنا ہوتا ہے، اور اُس لمحے کوئی سرنگ سوال کی حفاظت نہیں کرتی۔ اگر ہاٹ اسپاٹ پورٹل پتے سے جواب دے تو بات چیت ناکام ہو جاتی ہے یا لٹک جاتی ہے۔ اگر کچھ بھی جواب نہ دے تو کلائنٹ نام کی خرابی بتاتا ہے اور سرنگ کبھی شروع نہیں ہوتی۔ دونوں نتائج میں سے کوئی بھی ایسے خالی سرنگ لاگ کی وضاحت کرتا ہے جو ورنہ بے قصور لگتا ہے۔
آپریٹنگ سسٹم اپنی رابطہ جانچ اور پورٹل کی کھوج بھی چلاتے ہیں، جو RFC 8910 اور RFC 8952 میں بیان ہوئی ہیں، اور وہ درخواستیں کسی بھی VPN کے کھڑے ہونے سے پہلے باہر جاتی ہیں۔ اُنہیں پراکسی لاگ میں دیکھنا لیک کا ثبوت نہیں، متوقع رویہ ہے۔
عملی حل یہ ہے کہ کلائنٹ کو ایسا اختتامی نقطہ دیا جائے جسے کسی تلاش کی ضرورت نہ ہو۔ جب یہ ناممکن ہو تو پہلے سائن اِن مکمل کریں اور پھر جڑیں۔
پتہ لگائیں کہ کس حل کنندہ نے جواب دیا
براؤزر سے نہیں، سسٹم سے پوچھیں، اور سوال دو بار چلائیں: ایک بار اُس حل کنندہ کے ذریعے جو آلہ ابھی استعمال کر رہا ہے، ایک بار کسی مستقل پتے کے خلاف۔
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
پہلی کمانڈ کا جواب اگر تیسرے سے مختلف ہو تو یہ بتاتا ہے کہ مقامی حل کنندہ کچھ اور واپس کر رہا ہے، اور موڑنے والا ہاٹ اسپاٹ یہی کرتا ہے۔ تیسرے کی ناکامی پہلے کی کامیابی کے ساتھ پورٹل کی طرف اشارہ کرتی ہے: مقامی حل کنندہ نے سائن اِن پتہ پیش کیا جبکہ باہر جانے والا پورٹ 53 گرا دیا گیا۔ دونوں میں وقت ختم ہونے کا مطلب ہے کہ نیٹ ورک تصدیق مکمل ہونے تک DNS کو چھوڑ دیتا ہے۔
جڑنے کے بعد دہرائیں اور موازنہ کریں۔ کیش شدہ جواب تبدیلی سے بچ جاتا ہے، اس لیے کیش خالی کریں یا دوسرے مشاہدے کے لیے نیا نام پوچھیں۔
بعد کی تلاشیں اُسی راستے پر رکھیں جو آپ کا ارادہ تھا
DNS بھی پکڑنے والا مکمل سرنگ پروفائل سب سے سادہ ترتیب ہے: ہر ایپلی کیشن کا ہر سوال اُس حل کنندہ کو جاتا ہے جو سرنگ آگے بڑھاتی ہے، اور مقامی نیٹ ورک صرف خفیہ کردہ ٹریفک دیکھتا ہے۔ یہ جڑنے کے بعد اندرونی اور عوامی نام حل کر کے، پھر دونوں جوابات کا موازنہ سرنگ کے حل کنندہ کے تنہا واپس کرنے سے کر کے ثابت کریں۔
Split-DNS کو ارادے سے لکھی گئی ڈومین فہرست چاہیے: کارپوریٹ لاحقے سرنگ کے ذریعے، باقی سب مقامی طور پر، اور دونوں کے درمیان کوئی اوورلیپ نہیں۔
براؤزر کا محفوظ DNS اُس پالیسی سے باہر ہے، اس لیے اگر پروفائل کے متوقع رویے کے لیے اُسے بند ہونا ضروری ہو تو مشین کے لیے نہیں، اُس پروفائل کے لیے بند کریں۔ یہ سسٹم حل کنندہ میں ترمیم کر کے نہیں، براؤزر کی ترتیبات میں کریں، تاکہ تبدیلی اگلی بار نظر آئے۔ ہر جانچ کے لیے ایک سطر میں جواب، حل کنندہ اور رابطے کا مرحلہ لکھیں۔ ہوٹل کے Wi-Fi پر DNS ناکام ہونے کی رپورٹ کم از کم تین مختلف وجوہات والی علامت بیان کرتی ہے۔