Android VPN مکمل ہوسٹ نام حل کرتا ہے، مختصر نام نہیں

آپfilesٹرمینل ایمولیٹر میں لکھتے ہیں اور کچھ واپس نہیں آتا؛ آپfiles.corp.exampleلکھتے ہیں اور وہی سرور فوراً جواب دیتا ہے۔ VPN اسناد میں کچھ نہیں بدلا، اور نجی DNS سرور کبھی خراب نہیں ہوا۔ Android میں مختصر لیبل اور مکمل نام ریزالور سے مختلف راستوں پر جاتے ہیں، اور ان راستوں میں سے ایک ایسی سیٹنگ پر منحصر ہے جو ٹنل کے مالک کو فراہم کرنی ہوتی ہے۔ آپ کے سامنے فیصلہ یہ نہیں کہ کون سا DNS سرور بدلا جائے، بلکہ یہ ہے کہ ایپ جو نیٹ ورک واقعی استعمال کر رہی ہے اسے کون کنٹرول کرتا ہے۔

تلاش ڈومین پتہ نہیں ہے۔ یہ ان لاحقوں کی فہرست ہے جو ریزالور ننگے لیبل میں شامل کر کے پھر ہار مان جاتا ہے۔

تلاش لاحقہ اور DNS سرور الگ فیلڈ ہیں

ریزالور کا پتہ Android کو بتاتا ہے کہ کہاں پوچھنا ہے۔ تلاش لاحقہ بتاتا ہے کہ جب آپ صرف بائیں طرف کا لیبل دیں تو کیا پوچھنا ہے۔ دونوں ایک ہی نیٹ ورک آبجیکٹ پر رہتے ہیں، اور کوئی بھی اکیلا غائب ہو سکتا ہے۔

یہی آزادی بتاتی ہے کہ مکمل ہوسٹ نام کیوں کام کرتا ہے۔ پوری طرح اہل نام کو لاحقے کی ضرورت نہیں، کیونکہ وہ پہلے ہی وہ تار ہے جو سرور کو جاتی ہے۔

Android یہ تقسیم اس کے ذریعے دکھاتا ہےLinkProperties۔ DNS سروروں کی فہرست اور ڈومین تلاش کی فہرست ایک ہی آبجیکٹ پر ہیں، اور دوسری اکثر خالی ہوتی ہے چاہے پہلی پوری بھری ہو۔ وہ نیٹ ورک جس میں ریزالور ہے مگر ڈومین نہیں، ایسا نیٹ ورک ہے جہاں لاحقہ کبھی لاگو نہیں ہوا — وہ سرور نہیں جس نے مختصر نام رد کیا۔

کچھ بھی بدلنے سے پہلے موثر نیٹ ورک پڑھیں

Wi-Fi، موبائل نیٹ ورک اور VPN انٹرفیس تین الگ نیٹ ورک ہیں، اور ٹنل اوپر آتے ہی ڈیفالٹ بن جاتا ہے۔ اس لیے دفتر کے Wi-Fi پر چلنے والا لاحقہ ٹنل کے فعال رہنے کے دوران لاگو لاحقہ نہیں ہوتا۔ وہ نیٹ ورک دیکھیں جس پر ایپ واقعی منتخب ہے، وہ نہیں جو آپ نے پچھلے ہفتے ترتیب دیا تھا۔

ڈیوائس پر ٹرمینل شیل یہاں کمزور گواہ ہے، کیونکہ اس کاresolv.confہر ایپ کا نظریہ نہیں بلکہ ریزالور کا ایک نظریہ پیش کرتا ہے۔

براؤزر کی پتہ پٹیاں ایک اور تہہ شامل کرتی ہیں: ننگے لفظ کو تلاش استفسار سمجھا جا سکتا ہے، یا اس کے ذریعے حل کیا جا سکتا ہےبراؤزر کی اپنی انکرپٹڈ-DNS پالیسی، اس لیے Chrome میں کھلنے والا صفحہ سسٹم تلاش کے بارے میں کچھ ثابت نہیں کرتا۔ پلیٹ فارم کے ریزالور کو استعمال کرنے والی اور کیا واپس آیا چھاپنے والی چیز سے جانچیں۔ پھر مختصر شکل اور مکمل شکل ایک ہی سیشن میں، ایک ہی نیٹ ورک پر چلائیں، اور نوٹ کریں کہ کس نے جواب دیا۔

اگر آپ VPN ایپ بناتے ہیں تو بلڈر میں ہی لاحقہ منسلک کریں

جب آپ کی ایپ انٹرفیسVpnServiceکے ذریعے قائم کرتی ہے،addSearchDomainتو یہ اس کے لیے معاون ان پٹ ہے۔ یہ ایسی ڈومین تار لیتا ہےcorp.example، اور یہ سرور کا پتہ بھیجنے کا متبادل طریقہ نہیں ہے۔

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

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

اگر آپ صرف VPN استعمال کرتے ہیں، تو یہ آپ کے سیٹ کرنے کا کام نہیں

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

ڈیسک ٹاپ پروفائل دوبارہ درآمد کرنا موبائل نقشہ بندی کے بارے میں دوبارہ کچھ ثابت نہیں کرتا۔

تین شرطیں طے کرتی ہیں کہ آپ کے پاس خرابی ہے یا متوقع حد۔ پہلی، کیا ادارہ مختصر لیبل کو بالکل بھی معاون نام مانتا ہے، یا یہ ایسی سہولت ہے جو کبھی صرف دفتر کے Wi-Fi پر چلی؟ دوسری، کیا ناکام تلاش کسی براؤزر سے آ رہی ہے، جو سسٹم ریزالور کو مکمل طور پر بائی پاس کر سکتا ہے؟ تیسری، کیا مختصر نام ٹنل کے ذریعے قابل رسائی ہونا چاہیے، یا صرف LAN سے؟ اگر آخری جواب صرف-LAN ہے، تو لاحقہ شامل کرنے سے ایسا نام بنے گا جو دفتر سے باہر حل ہوگا اور پھر روٹ نہیں ہوگا۔

جب لاحقہ موجود ہو اور مختصر نام پھر بھی ناکام ہوں

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

پھر راستہ دیکھیں۔ جو پتہ حل ہوتا ہے مگر ٹنل اسے نہیں اٹھاتی، وہ جڑنے کے وقت ناکام ہوتا ہے، جو براؤزر میں خاموشی سے ہار ماننے والی تلاش کی ناکامی جیسا ہی لگتا ہے۔

سرٹیفکیٹ اپنے الگ ذکر کے حقدار ہیں۔ HTTPS تصدیق وہی ہوسٹ نام استعمال کرتی ہے جو آپ نے واقعی لکھا، اس لیے صحیح طور پر پھیلنے والا مختصر نام ہینڈ شیک میں پھر بھیfilesپیش کرتا ہے۔files.corp.exampleکے لیے جاری ہوا سرٹیفکیٹ اس کے لیے درست نہیں ہوگا، اور وہ خرابی درست رویہ ہے، آپ کے شروع کردہ DNS مسئلے کی علامت نہیں۔

اب آگے کیا کریں

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

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