Windows কেন আপনার VPN নামগুলো এমন একটি DNS সার্ভারে পাঠায় যা আপনি কখনো সেট করেননি

আপনি VPN অ্যাডাপ্টারে DNS সার্ভার সেট করলেন, আবার সংযোগ করলেন, তবুও ব্যক্তিগত নামটি ফিরে আসছে অফিসের রিজলভার থেকে, যা এই ল্যাপটপে কেউ কনফিগার করেনি। ফলাফলটি দেখে মনে হয় সেটিংটি উপেক্ষা করা হয়েছে, এবং এক অর্থে তা-ই হয়েছে, কারণ অ্যাডাপ্টার তালিকা একটি সিদ্ধান্ত নয়, বরং প্রার্থীর সমষ্টি। Windows নাম সমাধান করে নেমস্পেস নীতির মাধ্যমে, যা নির্দিষ্ট সাফিক্সের জন্য অন্য সার্ভার নির্ধারণ করতে পারে, এবং অ্যাডাপ্টার সেটিং দেখার আগেই সেই নীতি প্রয়োগ হয়। কোন টেবিল পড়তে হবে তা জানলে যে নিয়মটি জিতেছে তা খুঁজে বের করা পাঁচ মিনিটের কাজ।

আপনি কী বদলেছেন, আর আসলে কী সিদ্ধান্ত নেয়

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

এই কারণেই একই ল্যাপটপে দুটি নাম একই সময়ে ভিন্ন পথে যেতে পারে। কর্পোরেট সাফিক্সের অধীন হোস্ট নিজের নিয়ম অনুসরণ করে; পাবলিক নাম ডিফল্ট পথ অনুসরণ করে, যার অর্থ সাধারণত যে অ্যাডাপ্টার আগে উত্তর দেয়।

টেবিল কীভাবে নাম মেলায়

নিয়মগুলো নেমস্পেস দিয়ে চিহ্নিত, এবং সবচেয়ে নির্দিষ্ট মিল জেতে। corp.example-এর জন্য নিয়ম vpn.corp.example-এ প্রযোজ্য এবং example.net-এ প্রযোজ্য নয়। . নেমস্পেসের নিয়মটি অন্য নিয়মগুলো যাতে কভার করে না তা সব কভার করে, ফলে এটি তালিকার সবচেয়ে বিপজ্জনক এন্ট্রি এবং অসংশ্লিষ্ট কোনো সাইট টানেল দিয়ে সমাধান হলে যা পরীক্ষা করা উচিত।

একটি নিয়মের সাথে মন্তব্য, এন্ট্রিটিকে নিষ্ক্রিয় করার নীতি, এবং DNS ঠিকানার সাথে সম্পর্কহীন নিরাপত্তা সেটিংসও থাকতে পারে। নিষ্ক্রিয় নিয়ম কনফিগারেশনে দৃশ্যমান থাকে কিন্তু কোনো প্রভাব ফেলে না, তাই কাগজে সঠিক দেখানো এন্ট্রি প্রোফাইল পরিবর্তনের পরেও নিষ্ক্রিয় থাকতে পারে।

ইচ্ছার তালিকা নয়, কার্যকর টেবিল পড়ুন

কনফিগার করা নিয়ম আর কার্যকর নিয়ম দুটি আলাদা প্রশ্ন। Get-DnsClientNrptRule মেশিনে কী আছে তা তালিকাভুক্ত করে। Get-DnsClientNrptPolicy -Effective ক্লায়েন্ট আসলে কী প্রয়োগ করবে তা দেখায়, নীতি ও স্থানীয় সেটিংস থেকে মিলিত মানসহ।

ওই আউটপুটের সাফিক্সটি আপনি যে নাম পরীক্ষা করছেন তার সাথে অক্ষরে অক্ষরে মিলিয়ে দেখুন। corp.example-এর নিয়ম corp.example.com দিয়ে শেষ হওয়া নাম ধরে না, আর এক জায়গায় শেষে বিন্দু থাকা আর অন্য জায়গায় না থাকা মিলটি বদলানোর জন্য যথেষ্ট।

নিয়ম না থাকলে Windows একাধিক অ্যাডাপ্টারকে জিজ্ঞাসা করে

টেবিলে কিছুই যখন নামের দাবি করে না, তখন ক্লায়েন্ট কোয়েরিটি কয়েকটি ইন্টারফেস দিয়ে পাঠাতে পারে এবং যে উত্তর আগে আসে তা নিতে পারে। ফলাফল সময়নির্ভর: একই নাম সোমবার তারযুক্ত অ্যাডাপ্টার থেকে এবং মঙ্গলবার টানেল থেকে সমাধান হতে পারে, আর কোনো অ্যাডাপ্টারের কনফিগারেশনেই সেই পার্থক্যের ব্যাখ্যা নেই।

দুটি পথ আছে। সিদ্ধান্তটি যাতে আর দৌড় না হয় সেজন্য নেমস্পেসের জন্য নিয়ম যোগ করুন, অথবা DNS ক্লায়েন্ট নীতি দিয়ে সমান্তরাল আচরণ বন্ধ করুন এবং ধীর কিন্তু নির্ধারিত সমাধান মেনে নিন। প্রথমটি সাধারণত স্প্লিট-টানেল VPN-এর জন্য বেশি উপযুক্ত, কারণ এটি ক্রমের ওপর নির্ভর না করে উদ্দেশ্য নথিভুক্ত করে।

যে পথগুলো রিজলভার সম্পূর্ণ এড়িয়ে যায়

নিরাপদ DNS চালু থাকা ব্রাউজার নিজেই সমাধান করে এবং Windows-কে কেবল ঠিকানাটি দেয়, তাই নিয়মের টেবিল নামটি কখনো দেখে না। নিজস্ব রিজলভারযুক্ত রানটাইমে তৈরি ক্লায়েন্টও একইভাবে আচরণ করতে পারে। একই মেশিনে একটি অ্যাপ্লিকেশনে নাম সমাধান হয়ে অন্যটিতে ব্যর্থ হলে, নীতিতে হাত দেওয়ার আগে দুটি সমাধান-পথ তুলনা করুন।

অ্যাপটি আগের সেশনের ক্যাশে করা ঠিকানায় সংযোগ করছে কি না তাও দেখুন। Clear-DnsClientCache এবং তারপর একই লুকআপ পুরোনো ফলাফল থেকে অনুমান করার চেয়ে পরিষ্কার উত্তর দেয়।

যে নামটি ব্যর্থ হয়েছিল সেটি দিয়ে পরীক্ষা করুন

রিপোর্টের সঠিক হোস্টনেমটি সমাধান করুন, কোনো পাবলিক স্পিড-টেস্ট ডোমেইন নয়, এবং কোন সার্ভার উত্তর দিয়েছে তা লিখে রাখুন। তারপর একটি জিনিস বদলান: নিয়ম, অ্যাডাপ্টার তালিকা বা নীতি অ্যাসাইনমেন্ট, এবং পুনঃসংযোগের পর একই লুকআপ পুনরাবৃত্তি করুন যাতে প্রয়োগকৃত অবস্থা আবার তৈরি হয়।

নাম সমাধান হলে এবং সেবা এখনও প্রত্যাখ্যান করলে DNS সম্পাদনা বন্ধ করুন। পরের দরকারি ধাপ হলো ঠিকানা ও সেখানে যাওয়ার রুট, কারণ নাম সমাধান ইতিমধ্যে নিজের কাজ করে ফেলেছে।