VPN ব্যবহারকারী নথিভুক্ত করা: প্রথমে পরিচয়ের মালিক খুঁজুন
VPN ব্যবহারকারী যোগ করা শুরু হয় পরিচয় ব্যবস্থা থেকে, শেল থেকে নয়। কোন ব্যাকএন্ড অ্যাকাউন্ট যাচাই করে তা খুঁজুন, অধিকার দিন এবং প্রত্যাহার পরিকল্পনা করুন।
কেউ VPN অ্যাক্সেস চায়, আর প্রথম প্রবৃত্তি হলো সার্ভারে adduser চালানো। এই প্রবৃত্তি কেবল সংকীর্ণ কিছু স্থাপনায় সঠিক। কিছু তৈরির আগে সার্ভারের কনফিগারেশন খুলে দেখুন কোন পণ্য সেখানে চলে এবং কোথায় শংসাপত্র যাচাই করে, কারণ অ্যাকাউন্টটি পণ্যের ডেটাবেসে, পরিচয় প্রদানকারীতে বা হোস্টের নিজস্ব প্রমাণীকরণ স্তূপে থাকতে পারে। ভুল ধরনের অ্যাকাউন্ট তৈরি করলে ব্যক্তির কাছে কাজ করা লগইন থাকে কিন্তু টানেল থাকে না।
যে ক্লায়েন্ট প্রোফাইলে OpenVPN লেখা, তা প্রোটোকল বর্ণনা করে, তার পেছনের পরিচয় ব্যবস্থা নয়।
adduser থেকে নয়, সার্ভার থেকে শুরু করুন
প্রথমে পণ্যটি চিহ্নিত করুন। Community OpenVPN হলো ডেমন আর আপনি যে প্রমাণীকরণ যুক্ত করেছেন, আর Access Server হলো নিজস্ব ব্যবহারকারী স্তরযুক্ত একটি পণ্য। কনফিগারেশন, ইউনিটের নাম ও প্যাকেজ তালিকা চান, এবং ব্যবহারকারী ব্যবস্থাপনার জন্য ওয়েব ইন্টারফেস আছে কি না দেখুন। তারপর দেখুন স্থাপিত প্রোফাইল ক্লায়েন্টদের কাছ থেকে কীভাবে পরিচয় প্রমাণ আশা করে: শংসাপত্র, ব্যবহারকারীর নাম ও পাসওয়ার্ড, নাকি দুটোই। এই উত্তরই অ্যাকাউন্টের মালিক ব্যবস্থার নাম বলে দেয়।
তারপরেই ব্যবহারকারী তৈরির বাক্যটির কোনো অর্থ হয়। শুধু শংসাপত্রভিত্তিক স্থাপনায় এর অর্থ অনুমোদিত প্রক্রিয়ায় একটি ডিভাইস পরিচয় দেওয়া, আর Unix লগইন কিছুই বদলায় না। পাসওয়ার্ডভিত্তিক স্থাপনায় এর অর্থ সেই ব্যাকএন্ড যা সত্যিই পাসওয়ার্ড যাচাই করে।
চার ব্যাকএন্ড, অ্যাকাউন্ট তৈরির চার জায়গা
Access Server-এর স্থানীয় প্রমাণীকরণ অ্যাকাউন্ট নিজের ডেটাবেসে রাখে, তাই সেগুলো তৈরির ইন্টারফেস হোস্টের নয়, পণ্যের। PAM যাচাইকরণ অপারেটিং সিস্টেমের স্তূপে অর্পণ করে, তাই পরিষেবা সেই স্তূপটিই বেছে নিলে স্থানীয় Unix অ্যাকাউন্ট নথিভুক্তির অংশ হতে পারে। LDAP, RADIUS ও SAML যাচাইকরণ বাইরের পরিষেবায় সরিয়ে নেয়, যেখানে প্রভিশনিং, পাসওয়ার্ড নীতি ও MFA থাকে। Access Server চারটি ক্ষেত্রেই ব্যবহারকারীভিত্তিক শংসাপত্র ও অনুমতি ধরে রাখতে পারে, আর এটাই বিভাজনটিকে বিভ্রান্তিকর করে তোলে।
এই নির্দিষ্ট ব্যবহারকারীর জন্য কার্যকর পদ্ধতি দেখুন, বৈশ্বিক ডিফল্ট নয়। Access Server 2.10 ও পরবর্তীরা গ্রুপ বা ব্যবহারকারীভিত্তিক ভিন্ন প্রমাণীকরণ পদ্ধতি প্রয়োগ করতে পারে, তাই ডিফল্ট স্থানীয় হওয়া প্রমাণ করে না যে আপনার সামনের অ্যাকাউন্টটি স্থানীয়ভাবে যাচাই হয়।
অধিকার একটি আলাদা সিদ্ধান্ত
প্রমাণীকরণ বলে ব্যক্তি কে; অধিকার বলে সে কী পর্যন্ত পৌঁছাতে পারে। এগুলো দুটি ধাপ হিসেবে রাখুন, কারণ সফল লগইন কোনো অনুমতি নয়। উদ্দিষ্ট রুট, সম্পদ অনুমতি ও প্রশাসনিক অধিকার সচেতনভাবে দিন এবং অসম্পর্কিত অ্যাক্সেস অস্বীকৃতই থাকে তা নিশ্চিত করুন। যেখানে স্থাপনা ব্যক্তিগত পরিচয় সমর্থন করে, সেখানে অন্যের প্রোফাইল পাঠানোর বদলে প্রত্যেক ব্যক্তির জন্য একটি করে দিন, কারণ ভাগ করা প্রোফাইল একজন ব্যক্তির জন্য প্রত্যাহার করা যায় না।
ক্লায়েন্ট উপকরণও গুরুত্বপূর্ণ। স্বয়ংক্রিয় লগইন প্রোফাইল ও ইন্টারঅ্যাকটিভ ব্যবহারকারী লগইন ভিন্ন প্রমাণীকরণ সম্পর্ক বোঝায়, আর একটির বদলে অন্যটি দিলে সার্ভার আসলে কী যাচাই করে তা বদলে যায়।
অ্যাক্সেস প্রত্যাহার নথিভুক্তির অংশ
ব্যবহারকারী তৈরির সময়ই তিনজন মালিক লিখে রাখুন: কে অ্যাকাউন্ট যাচাই করে, কে VPN অ্যাক্সেসের অনুমতি দেয়, এবং কোন ডিভাইস বা প্রোফাইল সংযোগটির প্রতিনিধিত্ব করে। এরা তিনটি ভিন্ন ব্যবস্থা হতে পারে, আর যে প্রত্যাহার পরিকল্পনা কেবল একটির নাম নেয় সে একটি পথ খোলা রাখে। ব্যক্তি চলে গেলে তার মালিকের কাছ থেকে অধিকার সরান এবং জারি করা প্রতিটি শংসাপত্র তার মালিকের অধীনে প্রত্যাহার করুন। ডাউনলোড করা ফাইল মুছে ফেলা প্রত্যাহার নয়, আর বাইরের পরিচয় এখনও প্রমাণীকরণ করলে স্থানীয় এন্ট্রি মুছেও প্রত্যাহার হয় না।
তারপর নথিভুক্তি পরীক্ষা করুন যেভাবে আক্রমণকারী করত: নতুন পরিচয়ে একবার সংযোগ করুন, উদ্দিষ্ট সম্পদে অ্যাক্সেস নিশ্চিত করুন এবং অসম্পর্কিত সম্পদ এখনও অস্বীকার করে তা নিশ্চিত করুন। একবার কাজ করা প্রথম সংযোগ আর একটি নেতিবাচক পরীক্ষা মিলেই সম্পূর্ণ নথিভুক্তি।
রেকর্ডটি যে প্রোফাইলের, তার সঙ্গে রাখুন। পরবর্তী নিরীক্ষক জিজ্ঞাসা করবেন একটি নির্দিষ্ট মাসে কে সংযোগ করতে পারত, আর উত্তরটি ওই তিন মালিকের মধ্যে আছে।