VPN হোস্টনেম ব্যর্থ হয়, IP ঠিকানা কাজ করে: কোথায় দেখবেন

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

নাম এমন প্রশ্ন করে যা ঠিকানা করে না

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

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

টানেল আসলে যে রিজলভার বসিয়েছে সেটি পড়ুন

অপারেটিং সিস্টেমকে জিজ্ঞেস করুন অভ্যন্তরীণ জোনের কোয়েরি কোন রিজলভার সামলায়, VPN ক্লায়েন্টের ইন্টারফেস কোনটি বিজ্ঞাপন করে তা নয়। যে সার্ভার অভ্যন্তরীণ জোন ছাড়া একটি পাবলিক রিজলভার ঠেলে দেয়, সে ঠিক এই ব্যর্থতাই তৈরি করে, এবং এটি রাউটিং ত্রুটি নয়, কনফিগারেশন ত্রুটি।

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

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

Get-DnsClientNrptPolicy
ipconfig /all

অভ্যন্তরীণ জোন সঠিক সার্ভার দিয়ে রিজলভ হলে থামুন। রিজলভার আপনার সমস্যা নয়।

সাফিক্স ব্যর্থ সংক্ষিপ্ত নামের ব্যাখ্যা দেয়

কোয়েরি পাঠানোর আগে এক-লেবেলের নাম সংযোগের সাফিক্স তালিকা দিয়ে বাড়ানো হয়। VPN অভ্যন্তরীণ সাফিক্স না দিলে fileserver কখনোই fileserver.corp.example হয় না, এবং কোয়েরিটি এমন নাম হয়ে বেরিয়ে যায় যা কোনো পাবলিক রিজলভার জানে না। সাফিক্স ঠেলে দেওয়া, বা পূর্ণ নাম টাইপ করা, সার্ভারে কিছু না বদলেই অনুমানটি পরীক্ষা করে।

nslookup fileserver.corp.example
ping -a 192.168.50.20

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

সাফিক্স যোগ করলে ঠিক হয়ে গেলে, বাকি কাজ হলো প্রত্যেক ব্যবহারকারীকে তা টাইপ করতে বলা নয়, বরং VPN প্রোফাইলের মাধ্যমে সেই সাফিক্স পৌঁছে দেওয়া।

NetBIOS ও WINS আলাদা প্রক্রিয়া

পুরনো SMB এখনো NetBIOS নাম সেবা দিয়ে খালি নাম খুঁজতে পারে, যা ব্রডকাস্টে বা WINS সার্ভারের মাধ্যমে উত্তর দেয়। ব্রডকাস্ট একটি ব্রডকাস্ট ডোমেইনের ভিতরে থাকে এবং প্রথম রাউটারেই থেমে যায়, তাই টানেলের ওপারে পৌঁছাতে পারে না; WINS কাজ করে কারণ ক্লায়েন্টের নিবন্ধন ও কোয়েরির জন্য একটি ইউনিকাস্ট ঠিকানা থাকে। তাই শুধু IP বহনকারী VPN-ও পুরনো নাম সমর্থন করতে পারে, যখন WINS কনফিগার করা ও নাগালে থাকে।

nbtstat -n
nbtstat -R

আধুনিক SMB-র জন্য DNS ও পূর্ণ নামের ওপর নির্ভর করুন, আর পুরনো পথ অবসরে পাঠান। সত্যিই পুরনো হলে WINS দিন বা অ্যাপ্লিকেশনটি বদলান; মাঝের পথটি হলো এমন একটি সাপোর্ট সারি যা কখনো খালি হয় না।

হাঁটাপথ শেষ হয় যখন আপনি বলতে পারেন কোন স্তর ব্যর্থ হয়েছে: রিজলভার, সাফিক্স বা পুরনো আবিষ্কার। যে রিজলভার উত্তর দিয়েছে আর যে নাম-রূপ কাজ করেছে তা লিখে রাখুন, কারণ পরের মানুষটি একই লক্ষণ থেকে শুরু করবে।