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 সমস্যার উপসর্গ নয়, বরং সঠিক আচরণ।

এরপর কী করবেন

কিছুতে হাত দেওয়ার আগে বিভাজনটি নিশ্চিত করুন: পূর্ণ নাম সমাধান হয়, সংক্ষিপ্ত নাম হয় না, একই অ্যাপ, একই সেশন। তারপর নির্বাচিত নেটওয়ার্ক খুঁজে তার ডোমেইন সার্চ তালিকা রিজলভার তালিকার পাশে পড়ুন। দুটির মধ্যে যেটি খালি, সেটিই বলে দেয় কাকে কাজ করতে হবে — আপনি, যদি অ্যাপটির মালিক হন; টানেল অপারেটর, যদি না হন।

শেষে, বহনযোগ্যতা যেখানে গুরুত্বপূর্ণ সেখানে বুকমার্ক আর ক্লায়েন্ট কনফিগারেশনে পূর্ণ সার্ভিস হোস্টনেম পছন্দ করুন। এটি নেটওয়ার্ক বদল টিকে যায়, মোবাইল ফ্রন্টএন্ড হয়তো বাস্তবায়ন করে না এমন ম্যাপিংয়ের ওপর নির্ভর করে না, আর যে নামের জন্য সার্টিফিকেট ইস্যু হয়েছে তার সঙ্গে মেলে।