RADIUS অ্যাকাউন্টিং বনাম সফল লগইন: প্রত্যেকটি কী প্রমাণ করে

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

দুটি ভিন্ন প্রশ্ন

প্রমাণীকরণ সিদ্ধান্ত নেয় সংযোগ শুরু হতে পারবে কিনা, এবং এটি ঠিকানা পুল বা গ্রুপের মতো অ্যাট্রিবিউটসহ একটি রায় ফেরত দেয়। অ্যাকাউন্টিং পরবর্তী সেবাটি রেকর্ড করে, একটি সেশনের সাথে যুক্ত ঘটনার অনুক্রম হিসেবে।

তারা একই প্রোটোকলে এবং সাধারণত একই সার্ভারে যায়, ঠিক এই কারণেই মানুষ ধরে নেয় একটি অন্যটিকে বোঝায়।

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

তিন ধরনের রেকর্ড আপনাকে কী দেয়

Start রেকর্ড একটি সেশন খোলে, Interim-Update খোলা থাকাকালীন কার্যকলাপ জানায়, আর Stop তা বন্ধ করে। তিনটিই একটি সেশন শনাক্তকারী বহন করে যাতে প্রাপক সেগুলোকে একটি সেবা ঘটনার সাথে যুক্ত করতে পারে।

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

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

কেন ব্যবহারকারীনাম সেশন নয়

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

এই শর্টকাটই ব্যবহার প্রতিবেদনে অসম্ভব সময়কাল আনে দেয়।

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

PAM কোথায় মানায়, কোথায় মানায় না

OpenVPN-এর প্রমাণীকরণ প্লাগইন PAM-এর প্রমাণীকরণ ও অ্যাকাউন্ট-ব্যবস্থাপনা ধাপ আহ্বান করে। অ্যাকাউন্ট ধাপ যোগ্যতা যাচাই করে; এর নামের অর্থ ব্যবহার অ্যাকাউন্টিং নয়, এবং প্লাগইন PAM-এর সেশন খোলা ও বন্ধ করার হুক চালায় না।

কিছু PAM RADIUS মডিউল ঐ সেশন হুক দিয়ে অ্যাকাউন্টিং রেকর্ড পাঠাতে পারে, আর তা কেবল তখনই কাজ করে যখন অ্যাপ্লিকেশন সত্যিই সেগুলো আহ্বান করে।

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

চুক্তিটি প্রমাণ করে এমন একটি গ্রহণযোগ্যতা পরীক্ষা

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

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

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