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

একটি সেটিং, একটি পরিষেবা এবং একটি ভূমিকা; তিনটি প্রকাশক, তিনটি সুইচ।

রেকর্ড দিয়ে শুরু করুন, চেকবক্স দিয়ে নয়

ক্লায়েন্টরা প্রকৃতপক্ষে যে DNS সার্ভার ব্যবহার করে তার মাধ্যমে আক্রান্ত সার্ভারের সম্পূর্ণ নাম জিজ্ঞাসা করুন, এবং ফেরত আসা প্রতিটি ঠিকানা লিখে রাখুন। প্রতিটি ফেরত আসা ঠিকানাকে সার্ভারের প্রকৃত LAN ও টানেল ইন্টারফেসের সঙ্গে এবং ক্লায়েন্টরা যে নেটওয়ার্কে রয়েছে তার সঙ্গে মিলিয়ে দেখুন। একটি ঠিকানা স্থানীয়ভাবে সম্পূর্ণ বৈধ হয়েও গুরুত্বপূর্ণ ক্লায়েন্টদের জন্য অপ্রাপ্য হতে পারে। মাঝে মাঝে প্রমাণীকরণ ব্যর্থতা একটি সাধারণ উপসর্গ, কারণ ক্লায়েন্টরা ভিন্ন ভিন্ন প্রচেষ্টায় ভিন্ন ঠিকানা পায় বা বেছে নেয়।

মেশিনটি নিজের নাম সঠিকভাবে সমাধান করা খুব কমই প্রমাণ করে। গুরুত্বপূর্ণ পরীক্ষাটি চালানো হয় ক্লায়েন্ট নেটওয়ার্ক থেকে।

অ্যাডাপ্টার কেবল একটি প্রকাশক

অ্যাডাপ্টারের TCP/IP বৈশিষ্ট্যে সেই সংযোগের ঠিকানা নিবন্ধনের জন্য একটি চেকবক্স থাকে, এবং টিক তুলে দিলে ঠিক একটি প্রকাশক নীরব হয়। এটি অন্যগুলোকে থামায় না, তাই পুনরায় চালু করার পর রেকর্ডটি আবার দেখা দিতে পারে। যদি ডোমেইন কন্ট্রোলারটি DNS পরিষেবাও চালায়, সেই পরিষেবার নিজস্ব শোনার কনফিগারেশন এবং নিজস্ব নেম সার্ভার রেকর্ড থাকে। একাধিক ইন্টারফেসযুক্ত পরিবেশের জন্য মাইক্রোসফটের নির্দেশিকা ইন্টারফেসের আচরণ, DNS পরিষেবা এবং Netlogon-কে পৃথক প্রাসঙ্গিক প্রকাশক হিসেবে বিবেচনা করে।

তিনটি সুইচ, তিনজন মালিক, এবং তাদের মধ্যে কেবল একজনই অ্যাডাপ্টারের বৈশিষ্ট্য পাতায় থাকে।

DNS পরিষেবার নিজস্ব ঠিকানা আছে

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

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

পরিষ্কারের আগে মালিকানা

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

শেষে আপনি চান একটি পরিচিত প্রকাশিত ঠিকানা ও শ্রোতার সেট, যখন দৈনন্দিন ডোমেইন নিবন্ধন এখনও নিজের কাজ করছে। হাতে পরিষ্কারের ঠিক পরে যে মেশিনের নাম স্রেফ কাকতালীয়ভাবে সঠিকভাবে সমাধান হয়, সেটি তা নয়।

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

সম্পর্কিত নিবন্ধ