কেন ডায়াল-ইনের পরে সার্ভারের নামটি তার VPN ঠিকানায় রিজলভ হয়

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

দুটি ঠিকানা, একটি নাম, তিনটি শর্ত

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

তিনটি শর্ত মেরামত নির্ধারণ করে। প্রথমত, অতিরিক্ত ঠিকানাটি কি যেসব ক্লায়েন্ট তা পায় তাদের কাছে পৌঁছানো যায়? দ্বিতীয়ত, কোনো ভোক্তা কি এখনও সেই নিবন্ধনের উপর নির্ভর করে? তৃতীয়ত, রেকর্ডটি কি গতিশীল এবং তাই ফিরে আসতে সক্ষম, নাকি স্থির এবং তাই ইচ্ছাকৃত এন্ট্রি?

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

রেজিস্ট্রার বদলানোর আগে রেকর্ডটি পড়ুন

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

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

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

রেকর্ডের টাইমস্ট্যাম্প এবং DNS কনসোলটি এটিকে গতিশীল দেখায় কি না তা লিখে রাখুন। ওই একটি বৈশিষ্ট্যই বলে দেয় উপরের তিনটি শর্তের কোনটি প্রযোজ্য, আর এটাই পাঁচ মিনিটের পরিষ্কার আর টিকে থাকা মেরামতের মধ্যে পার্থক্য।

প্রকাশক ঠিক করুন, নাকি রেকর্ড ঠিক করুন, কিন্তু কোনটি জেনে নিন

রেকর্ডটি গতিশীল ও অবাঞ্ছিত হলে টেকসই সমাধান হলো সেই ইন্টারফেসকে নিবন্ধন করা থেকে বিরত রাখা। Windows প্রতি-ইন্টারফেস নিবন্ধন সেটিংস দেয়, আর DNS ক্লায়েন্ট পরিষেবা পরের সংযোগ বা ঠিকানা পরিবর্তনে আবার প্রকাশ করে। ডায়াল-ইন অ্যাডাপ্টারের নিবন্ধন বন্ধ করলে LAN অ্যাডাপ্টারের নিবন্ধন অক্ষত থাকে, যা সাধারণত আপনি চান।

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

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

যে ক্লায়েন্ট নেটওয়ার্ক ব্যর্থ হয়েছিল সেখান থেকে যাচাই করুন

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

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

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

অবশেষে, যে ঘটনাটি আগে ঠিকানাটি নিয়ে আসত সেটি পুনরাবৃত্তি করুন: VPN ক্লায়েন্ট আবার সংযুক্ত করুন, অথবা ডায়াল-ইন সেশন নবায়ন করুন। সেই জীবনচক্র পরিবর্তনের পরে প্রকাশিত নামটি আবার দেখুন। যে মেরামত কেবল পরের সংযোগ পর্যন্ত টেকে তা ছিল পরিষ্কার, মেরামত নয়, আর আপনি কোনটি করেছিলেন তা জানাই টিকিট বন্ধ করা আর পরের সপ্তাহে আবার খোলার মধ্যে পার্থক্য।