NPS RADIUS ক্লায়েন্ট হিসেবে আপনি কোন ঠিকানাটি নিবন্ধন করেন?

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

গেটওয়ে নিবন্ধন করুন, ল্যাপটপ বা পুল নয়

RADIUS ক্লায়েন্ট অবজেক্টটি সেই নেটওয়ার্ক অ্যাক্সেস ডিভাইসকে প্রতিনিধিত্ব করে যা প্রমাণীকরণ অনুরোধ পাঠায়। সেটি VPN গেটওয়ে, ক্লায়েন্ট চালানো প্রতিটি ল্যাপটপ নয়, এবং টানেলের ভিতরে বিতরণ করা ঠিকানার পরিসরও নয়।

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

আপনি যে ঠিকানা লিখবেন তা তিনটি শর্ত নির্ধারণ করে

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

দুই প্রান্তের একটি রেকর্ড জোড়াটি সোজা রাখে। নিচের সারণিটি দৃষ্টান্তের জন্য ব্যক্তিগত ঠিকানা ব্যবহার করে, তাই আপনার পথ সত্যিই যেগুলো ব্যবহার করে সেগুলো দিয়ে প্রতিস্থাপন করুন।

অনুমান না করে উৎসটি নিশ্চিত করুন। একটি প্রচেষ্টার সময় NPS বা ফায়ারওয়াল লগ দেখুন, অথবা NPS হোস্টে sudo tcpdump -ni any udp port 1812 দিয়ে ক্যাপচার করুন। সেই ক্যাপচারের ঠিকানাই ক্লায়েন্ট এন্ট্রির একমাত্র যুক্তিসঙ্গত উত্তর। গেটওয়ের যদি কয়েকটি সম্ভাব্য উৎস থাকে, প্রতিটিকে তার নিজস্ব বন্ধুত্বপূর্ণ নামে নিবন্ধন করুন।

শেয়ার্ড সিক্রেট হলো গেটওয়ে ও NPS-এর মধ্যে একটি মান

শেয়ার্ড সিক্রেট ডিভাইস সম্পর্কটি প্রমাণ করে। এটি ব্যবহারকারীর পাসওয়ার্ড নয় এবং কখনো কর্মীদের মধ্যে বিতরণ করা হয় না বা ক্লায়েন্ট প্রোফাইলে এমবেড করা হয় না।

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

একটি অনুমোদিত অনুরোধ দিয়ে নিশ্চিত করুন

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

শেষে, ফেরত দেওয়া অনুমোদন নিয়ে গেটওয়ে কী করে তা দেখুন। RADIUS ক্লায়েন্ট নিবন্ধন কেবল ডিভাইসটিকে অংশগ্রহণের অনুমতি দেয়; এটি প্রতিটি ফলে তৈরি সেশনকে LAN-এ প্রবেশাধিকার দেয় না।

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