RADIUS Access-Challenge-এর পরে VPN লগইন আটকে যায়
Access-Challenge কোনো সাফল্য নয়, চূড়ান্ত প্রত্যাখ্যানও নয়। NAS, গেটওয়ে ও ক্লায়েন্টকে একই বিনিময়ে পরের উত্তর কীভাবে বহন করতে হবে তা দেখুন।
আপনার পাসওয়ার্ড সঠিক, তবুও VPN লগইন ব্যর্থ হচ্ছে, আর RADIUS সার্ভার হয়তো ঠিক সেই কাজটিই করেছে যা তাকে বলা হয়েছিল। গেটওয়ে সম্ভবত একটি Access-Challenge পেয়েছে, উপযোগী কিছু দেখায়নি, তারপর সময় শেষ হয়েছে বা সেই উত্তরকে প্রত্যাখ্যান হিসেবে ধরেছে। ক্লায়েন্টের দিক থেকে এটি ভুল ক্রেডেনশিয়াল বা ভাঙা টানেলের মতো দেখায়। কারণ সাধারণত এমন একটি কথোপকথনের মাঝখানে থাকে যা কেউ ধারণ করেনি।
একটি লগইন, দুটি RADIUS বিনিময়
ব্যাকএন্ড যখন দ্বিতীয় ফ্যাক্টর চায়, তখন সে প্রথম অনুরোধের উত্তর গ্রহণ বা প্রত্যাখ্যান দিয়ে দেয় না। সে কোড 11 দিয়ে উত্তর দেয় এবং ব্যবহারকারীর পরের উত্তরের জন্য অপেক্ষা করে, যা গেটওয়েকে একটি অনুসরণকারী অনুরোধে ফেরত পাঠাতে হয়। সেই অনুসরণকারী অনুরোধ একই প্রমাণীকরণ কথোপকথনের অংশ, নতুন কোনো লগইন প্রচেষ্টার নয়।
কাজ করা ব্যবস্থায় ব্যবহারকারী দ্বিতীয় প্রম্পট দেখে: আগে পাসওয়ার্ড, তারপর একবার ব্যবহারযোগ্য কোড, অথবা অপারেটর নথিভুক্ত করে থাকলে একটি সম্মিলিত প্রম্পট। ভাঙা ব্যবস্থায় দ্বিতীয় প্রম্পট কখনও আসে না এবং লগইন কেবল ব্যর্থ হয়।
এটাই সেই লক্ষণ যা খুঁজতে হবে, আর শুধু ক্লায়েন্টের দিক থেকেই তা নিশ্চিত করা সহজ: VPN ক্লায়েন্ট যদি ঠিক একটি গোপন তথ্য চায় এবং তারপর এমন পাসওয়ার্ড প্রত্যাখ্যান করে যা আপনি জানেন বৈধ, তবে বিনিময়টি সম্ভবত চ্যালেঞ্জেই শেষ হয়েছে।
চ্যালেঞ্জ আসলে কী বহন করে
RADIUS স্পেসিফিকেশন 4.4 অনুচ্ছেদে কোড 11 বর্ণনা করে এবং এখানে গুরুত্বপূর্ণ দুটি অ্যাট্রিবিউট অনুমোদন করে। Reply-Message ব্যবহারকারীর জন্য নির্দিষ্ট পাঠ্য ধরে, আর State এমন একটি অস্পষ্ট মান ধরে যা সার্ভার ফেরত চায়। NAS-এর State ব্যাখ্যা করার কথা নয়, কেবল অপরিবর্তিত ফেরত দেওয়ার।
অনুসরণকারী অনুরোধ নতুন Identifier ও নতুন Request Authenticator ব্যবহার করে, এবং এটি অবশ্যই একই State মান এবং ব্যবহারকারীর উত্তর বহন করবে। সার্ভার সেই State-এর মাধ্যমে এটিকে অপেক্ষমাণ চ্যালেঞ্জের সঙ্গে মেলায়, তাই যে গেটওয়ে অ্যাট্রিবিউটটি পুনরায় তৈরি করে বা ফেলে দেয় সে এই প্রক্রিয়া সম্পূর্ণ করতে পারে না। প্রতিটি উত্তরের response authenticator-ও যাচাই হতে হবে, নয়তো NAS প্যাকেটটি বাতিল করবে।
4.4 অনুচ্ছেদ সেই বিবরণ যোগ করে যা বেশিরভাগ নীরব ব্যর্থতা ব্যাখ্যা করে: যে NAS চ্যালেঞ্জ সমর্থন করতে পারে না, সে Access-Challenge-কে প্রত্যাখ্যান হিসেবে ধরে। আপনার গেটওয়ের VPN সেবা যদি সেই সমর্থনের আগের হয় বা তা বাদ দেয়, তবে ব্যাকএন্ডের দ্বিতীয় ফ্যাক্টরের অনুরোধ কোনো প্রম্পট ছাড়াই তাৎক্ষণিক «প্রমাণীকরণ ব্যর্থ» হয়ে যায়।
শৃঙ্খলিত অনুরোধ কোথায় হারায়
প্রথম সন্দেহভাজন ক্রেডেনশিয়াল নয়, প্রম্পটের পথ। ওয়েব লগইনের জন্য OTP ক্ষেত্র দেখানো পোর্টাল স্বয়ংক্রিয়ভাবে VPN সেবার জন্যও তা করে না, আর কিছু গেটওয়ে কেবল সেই ক্লায়েন্টদের চ্যালেঞ্জ পাঠায় যারা সামর্থ্য ঘোষণা করে। একই অ্যাকাউন্ট দুই প্রবেশপথে পরীক্ষা করুন; পোর্টাল কাজ করলে আর VPN না করলে, আপনি হস্তান্তরের দিকে তাকিয়ে আছেন, টোকেনের দিকে নয়।
ইনপুট ফরম্যাট দ্বিতীয় সন্দেহভাজন। বিক্রেতার নথিভুক্ত বিভাজক ছাড়া পাসওয়ার্ড ও কোড জোড়া দেওয়া, বা সংরক্ষিত ক্রেডেনশিয়ালকে পুরোনো কোড পুনরায় চালাতে দেওয়া, এমনভাবে ব্যর্থ হয় যা ভুল পাসওয়ার্ডের সঙ্গে হুবহু একই দেখায়। অপারেটরের নথিভুক্ত আলাদা প্রম্পট বা সম্মিলিত ফরম্যাট ব্যবহার করুন, এবং কখনও নিজে বিভাজক বানাবেন না।
সংস্করণভিত্তিক ত্রুটি আছে, কিন্তু বছরের পর বছর আগের সংশোধিত সংস্করণের তালিকা আজকের স্থাপনার জন্য নির্ণয় নয়। আপনি যে সফটওয়্যার সত্যিই চালান তার রিলিজ নোট পড়ুন, আর পর্যবেক্ষণ করা বিনিময় পর্যায়কে প্রমাণ হিসেবে রাখুন।
একটি প্রচেষ্টা শুরু থেকে শেষ পর্যন্ত অনুসরণ করুন
সার্ভার-সাইড ডিবাগিং চালু রেখে একবার পুনরুৎপাদন করুন, এবং অন্য সব সেশন ক্যাপচার উইন্ডোর বাইরে রাখুন:
$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123
আউটপুটে একটি লাইনের বদলে কথোপকথনের আকৃতি খুঁজুন। Identifier 3 সহ প্রথম Access-Request, State বহনকারী একটি Access-Challenge, তারপর Identifier 4 সহ দ্বিতীয় Access-Request যা সেই State পুনরাবৃত্তি করে এবং ব্যবহারকারীর উত্তর অন্তর্ভুক্ত করে। দ্বিতীয় অনুরোধ অনুপস্থিত থাকলে গেটওয়ে কখনও অনুসরণ করেনি। এটি State ছাড়া এলে সার্ভার অপেক্ষমাণ চ্যালেঞ্জের সঙ্গে মেলাতে পারে না এবং সাধারণত প্রত্যাখ্যান করে।
ট্রেস শেয়ার করার সময় ক্রেডেনশিয়াল, টোকেন ও অপ্রয়োজনীয় পরিচয় তথ্য লুকান, এবং একাধিক ব্রাউজার ট্যাবের পুনঃপ্রচেষ্টা মেশানোর বদলে একক প্রচেষ্টার ঘটনাগুলো সম্পর্কিত করুন। টাইমস্ট্যাম্প এখানে আপনার বন্ধু; ক্লায়েন্ট হাল ছাড়ার পরে আসা চ্যালেঞ্জ ব্যবহারকারীর কাছে প্রত্যাখ্যান আর লগে ধীর উত্তর মনে হয়।
আপনার কাঙ্ক্ষিত সমাপ্ত অবস্থা হলো একটি সম্পূর্ণ, অনুমোদিত কথোপকথন এবং তার পরে অভীষ্ট সেবা প্রবেশ। RADIUS সার্ভার থেকে আসা একটি উত্তর এর চেয়ে অনেক কম প্রমাণ করে।