পাবলিক DNS কাজ করলেও Active Directory পাওয়া যায় না

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

ভ্রান্ত ধারণা: নাম রিজলভ হয়, তাই DNS শেষ

একটি পাবলিক সাইট রিজলভ হওয়া কেবল বলে যে কোনো একটি রিজলভার পাবলিক জোনের একটি নামের জন্য একটি A বা AAAA কোয়েরির উত্তর দিয়েছে। Active Directory একই প্রোটোকল ব্যবহার করে ভিন্ন প্রশ্নের জন্য: ডোমেইনের সার্ভিসগুলো কোথায়, এবং এই ক্লায়েন্টের কোন কন্ট্রোলার ব্যবহার করা উচিত। প্রশ্নটি ডোমেইনের নামে নামকরণ করা জোনের অধীনে SRV রেকর্ড হিসেবে প্রকাশ করা হয়, আর একটি রিকার্সিভ পাবলিক রিজলভারের সেগুলো রাখার কোনো কারণ নেই।

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

একটি ডোমেইন ক্লায়েন্ট আসলে কী চায়, ক্রম অনুসারে

corp.example-এর মতো ডোমেইনের জন্য সাধারণ লোকেটর কোয়েরি হল _ldap._tcp.dc._msdcs.corp.example। SRV উত্তরগুলো প্রার্থী কন্ট্রোলার ও তাদের পোর্টের নাম দেয়, আর এরপর সংযোগ খোলার আগে ক্লায়েন্টের ওই হোস্টনেমগুলোর ঠিকানা রেকর্ড দরকার। সাইট-সচেতন ডিসকভারি সাইট সাবডোমেইনের অধীনে কোয়েরি যোগ করে, এবং উত্তরগুলো ঠিক করে কোন কন্ট্রোলারগুলো পছন্দনীয়, কোনটি বাধ্যতামূলক তা নয়।

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

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

কেন পাবলিক রিজলভার উত্তর দেয় তবু সাইন-ইন ভাঙে

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

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

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

টানেলের DNS ও তার রুট পরস্পর মিলিয়ে রাখুন

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

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

একটি ডিসকভারি কল ও একটি জীবন্ত কাজ দিয়ে গ্রহণ করুন

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

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

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