সংক্ষিপ্ত অভ্যন্তরীণ নাম VPN-এ ব্যর্থ হয়: যে প্রত্যয় আপনি কখনও দেখেন না
সংক্ষিপ্ত নাম কেবল কাজ করে কারণ একটি অনুসন্ধান প্রত্যয় এটি সম্পূর্ণ করে। প্রত্যয়ের ঘাটতি ও রিজলভার ব্যর্থতার মধ্যে পার্থক্য করতে পূর্ণ নাম ও সংক্ষিপ্ত নাম তুলনা করুন।
সংক্ষিপ্ত নামটি অফিসে কাজ করত এবং VPN-এ ব্যর্থ হয়, অথচ পূর্ণ নামটি ঠিকঠাক রিজলভ হয়। কিছুই নষ্ট হয়নি। intranet-এর মতো খালি নাম কোনো পূর্ণ নাম নয়; ক্লায়েন্ট তার অনুসন্ধান তালিকা থেকে একটি প্রত্যয় যোগ করে এবং ফলাফল চায়। VPN প্রোফাইল যদি সেই প্রত্যয় না দেয়, পরিচিত সংক্ষিপ্ত রূপটির অস্তিত্ব থাকা বন্ধ হয়ে যায়।
এটাই পুরো কল্পকথা। DNS ভাঙেনি, অনুসন্ধান নীতি বদলেছে।
খালি নাম কোনো নাম নয়
যখন আপনি একটি একক লেবেল টাইপ করেন, রিজলভারকে সিদ্ধান্ত নিতে হয় কী জিজ্ঞাসা করবে। সে নামটি যেমন আছে তা চেষ্টা করে, তারপর কিছু উত্তর না দেওয়া পর্যন্ত অনুসন্ধান তালিকার এন্ট্রিগুলো একে একে যোগ করে। Linux-এ resolv.conf search ও ndots সেটিংস দিয়ে সেই ক্রম নিয়ন্ত্রণ করে। Windows-এ প্রত্যয় তালিকা ও নাম-রিজলিউশন নীতি একই কাজ করে। প্রত্যয়টি সরিয়ে দিন, রিজলভারের যোগ করার কিছু থাকবে না।
তাই কাজ করা সংক্ষিপ্ত নাম একটি নীতির প্রমাণ, সুস্থ DNS সার্ভারের প্রমাণ নয়।
প্রত্যয় তালিকা ও রিজলভার ঠিকানা আলাদাভাবে কী করে
এই দুটিকে নিয়মিত গুলিয়ে ফেলা হয়। রিজলভার ঠিকানা বলে কাকে জিজ্ঞাসা করবেন; প্রত্যয় তালিকা বলে কোন নাম নিয়ে জিজ্ঞাসা করবেন। VPN আপনাকে প্রত্যয়হীন একটি ব্যক্তিগত রিজলভার দিতে পারে, বা ভুল রিজলভারসহ একটি প্রত্যয়। এই ব্যর্থতাগুলোর মধ্যে কেবল একটি DNS বিভ্রাটের মতো দেখায়।
এগুলো আলাদা করে পরীক্ষা করুন, কারণ ভুলটি ঠিক করতে গেলে একটি সাপোর্ট সময়কাল নষ্ট হয়।
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
তিনটি লক্ষণ, তিনজন ভিন্ন মালিক।
আগে পূর্ণ নাম পরীক্ষা করুন
প্রশাসকের নথিভুক্ত সম্পূর্ণ যোগ্যতাসম্পন্ন নাম চান, অনুমান নয়। কাজ করা FQDN প্রমাণ করে রিজলভার পৌঁছানো যায় এবং রেকর্ডটি আছে, যা এক প্রশ্নেই সম্ভাব্য অর্ধেক কারণ দূর করে। এমন টুল ব্যবহার করুন যা দেখায় কোন সার্ভার উত্তর দিয়েছে, যাতে ক্যাশে করা ফলাফল পড়তে না হয়।
পরীক্ষাটি গোপন রাখুন। অভ্যন্তরীণ রূপগুলো একটি পাবলিক রিজলভারে পাঠানো নাম প্রকাশ করে এবং কেউ যার পরিকল্পনা করেনি এমন নীতি পরীক্ষা করে।
সমাধান কোথায় থাকা উচিত
মালিক প্রোফাইল বা এটি তৈরি করা ব্যবস্থাপনা সিস্টেমটি সংশোধন করুন। স্থানীয় রিজলভার কনফিগারেশনে হাতে করা পরিবর্তন সাধারণত পুনঃসংযোগে হারিয়ে যায়, নয়তো মেশিনটি যে কোনো নেটওয়ার্কে যোগ দেয় সেখানে প্রযোজ্য হয়, যা আরও খারাপ।
Windows-এ আপনার মনে থাকা চেকবক্স নয়, কার্যকর নীতি দেখুন। Get-DnsClientNrptPolicy প্রকৃতপক্ষে বলবৎ নাম-রিজলিউশন নিয়মগুলো দেখায়।
macOS-এ scutil --dns প্রতিটি স্কোপযুক্ত ইন্টারফেসের জন্য রিজলভার কনফিগারেশন ছাপে, যার মধ্যে VPN যে অনুসন্ধান ডোমেইনগুলো পাঠিয়েছে সেগুলোও আছে।
Linux-এ /etc/resolv.conf-এর search লাইনটি পড়ুন, তবে কোনো VPN ক্লায়েন্ট এটি পুনর্লিখন করেছে কিনা দেখুন। ফাইলটি পরিচালিত হলে রেন্ডার করা ফাইলের বদলে সত্যের উৎস সম্পাদনা করুন। আগের নেটওয়ার্ক থেকে পড়ে থাকা পুরনো search লাইন একটি সাধারণ কারণ।
প্রোফাইলের সাথে কী রাখবেন
সংশোধিত পূর্ণ নাম, প্রত্যয় তালিকা ও রিজলভার ঠিকানা ক্লায়েন্ট প্রোফাইলের পাশে রাখুন। পরের যে ব্যক্তি জানাবে intranet সাইটটি বন্ধ, সে শূন্য পাতা থেকে শুরু না করে তিনটি জানা মান তুলনা করতে পারবে।
আর যদি কেবল সংক্ষিপ্ত রূপটি ব্যর্থ হয়, টিকিটে তা লিখুন। ওই একটি বাক্য রিজলভার দলকে একটি বিকেল বাঁচায়।