জরুরি অবস্থার জন্য একটি স্থানীয় অ্যাকাউন্ট রাখা প্রত্যাখ্যাত প্রতিটি লগইনকে দ্বিতীয় সুযোগ করে দেয় না। Cisco IOS ও IOS XE-এর AAA মডেলে ওই ডেটাবেসে কেবল তখনই দেখা হয় যখন আগের মেথড নির্দিষ্ট ভাবে ব্যর্থ হয়, আর প্রত্যাখ্যান দিয়ে উত্তর দেওয়া RADIUS সার্ভার ওই ভাবে ব্যর্থ হয়নি। স্থানীয় অ্যাকাউন্ট অপ্রাপ্য মেথড ঢাকে, প্রত্যাখ্যাত মেথড নয়। বিপরীত মনে করলে একটি নীতি-সিদ্ধান্ত এমন সার্ভার ত্রুটির খোঁজে পরিণত হয় যা নেই।

মেথড তালিকা কেন সিঁড়ির মতো দেখায়

যেমন একটি লাইন aaa authentication login default group radius local বাঁ থেকে ডানে পড়া হয়, আর বেশিরভাগ মানুষ এটি পড়ে এই ভাবে যে আগে RADIUS চেষ্টা করো, তারপর স্থানীয় ডেটাবেস চেষ্টা করো। বাক্য গঠন ওই পাঠকে আমন্ত্রণ জানায়, কারণ একটি তালিকা একটি ক্রম। অর্থ আরও সংকীর্ণ: তালিকাটি প্রমাণীকরণের মেথডগুলোর নাম দেয়, আর এক মেথড থেকে পরেরটিতে যাওয়ার নিয়ম আগের মেথডের ফলাফলের উপর নির্ভর করে, ব্যবহারকারীকে আরেকটি চেষ্টা দেওয়ার উপর নয়।

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

মেথড তালিকাকে সার্ভার গ্রুপ থেকে আলাদা করুন

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

AAA কনফিগারেশন ছাপুন এবং সেবাটি যে তালিকা নির্দেশ করে তা পড়ুন, আপনি লিখেছিলেন বলে মনে করা ডিফল্ট নয়। এটি করুন সেই ডিভাইস থেকে যেখানে সেবাটি আসলে শেষ হয়।

show running-config | section aaa
show radius server-group RAD-GRP
show aaa servers

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

লগ পড়ার আগে রিপ্লাই পড়ুন

রিপ্লাই কোড ফলাফলের নাম দেয় এবং নিজের পরের ধাপ ইঙ্গিত করে। Access-Reject মানে ব্যাকএন্ড একটি সিদ্ধান্ত নিয়েছে, তাই কাজের প্রমাণ হলো যে নীতি মিলেছে এবং তার পিছনের অ্যাকাউন্ট অবস্থা। Access-Challenge মানে বিনিময়টি দ্বিতীয় ফ্যাক্টরের মতো আরেকটি সমর্থিত ধাপ চায়, আর স্থানীয় ফলব্যাক নীতির দাবি করা কিছু নীরবে বাদ দিয়ে যেত।

মনোনীত একটি পরীক্ষা অ্যাকাউন্ট দিয়ে একটি চেষ্টা পুনরুৎপাদন করুন যাতে রিপ্লাই ও ব্যাকএন্ড রেকর্ড একই টাইমস্ট্যাম্পে তুলনা করা যায়। এমন শংসাপত্র ব্যবহার করুন যা ব্যর্থ করার অনুমতি আপনার আছে।

test aaa group RAD-GRP svc-ops 'LabPass!24' legacy
debug radius authentication

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

স্থানীয় অ্যাকাউন্ট কেন কখনো কিছু প্রমাণ করেনি

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

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

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

রক্ষণাবেক্ষণ উইন্ডোতে ফলব্যাক পথ যাচাই করুন

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

প্রতিটি যাচাই একটি কনসোল সেশন বা আউট-অব-ব্যান্ড পথ থেকে চালান, যাতে ভুল আপনি যে সেশনে কাজ করছেন তা বন্ধ করতে না পারে। কনসোলই একমাত্র পথ যা পরীক্ষাধীন উপাদানের উপর নির্ভর করে না।

show aaa servers
show running-config | include aaa authentication
test aaa group RAD-GRP svc-ops 'LabPass!24' legacy

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

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