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

রিয়েলম কী নির্বাচন করে

গেটওয়ে একটি ব্যবহারকারীনাম পায় এবং কোথায় যাচাই করবে তা ঠিক করতে হয়। রিয়েলম হলো সেই নামের অংশ, বা তার পাশের অ্যাট্রিবিউট, যা ডেটাবেস বেছে নেয়: একটি ডিরেক্টরি, একটি RADIUS পুল, একটি স্থানীয় অ্যাকাউন্ট ফাইল। মাইক্রোসফটের NPS এটিকে রিয়েলম নাম বলে সংযোগ অনুরোধ পাঠায়, আর EAP নেটওয়ার্ক অ্যাক্সেস আইডেন্টিফায়ার একই ধারণা RFC 7542-এ @ চিহ্নের পরে প্রত্যয় হিসেবে বহন করে। দুটোই নির্বাচক, এবং কোনোটিই ঠিক করে না ক্রেডেনশিয়াল ভালো কি না।

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

রিয়েলমের সিনট্যাক্স ডিপ্লয়মেন্টের অন্তর্গত। কিছু পরিষেবা অ্যাট্রিবিউটসহ অযোগ্য নাম চায়, অন্যরা user@domain চায়, আর অল্প কিছু ব্যাকস্ল্যাশযুক্ত রূপ আশা করে যা বেশিরভাগ নির্দেশিকা কখনও উল্লেখ করে না।

ব্যাকএন্ড যে রূপ আশা করে তা ব্যবহার করুন

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

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

ব্রাউজার ও মেইল ক্লায়েন্ট কখনও আগের পরিচয় ক্যাশে রেখে নীরবে আবার পাঠায়। প্রতিবেদিত ব্যবহারকারীনাম টাইপ করা নাম থেকে আলাদা হলে সেই ক্যাশই প্রথম দেখার জায়গা।

প্রক্সির মধ্য দিয়ে অনুরোধ অনুসরণ করুন

FreeRADIUS ফ্রন্টএন্ডে প্রক্সি কনফিগারেশনে রিয়েলম ঘোষণা করা হয়, আর ঘোষিত প্রত্যয় ঠিক করে কোন হোম সার্ভার অনুরোধ পাবে। কিছু পরিবর্তনের আগে সেই ফাইল পড়ুন, কারণ কোনও রিয়েলমের সঙ্গে না মেলা অনুরোধ ডিফল্টভাবে স্থানীয়ভাবে প্রক্রিয়া করা হয়।

grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'

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

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

প্রচেষ্টা ফাঁস না করে লিখে রাখুন

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

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

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