কেন একটি .ovpn ফাইল সম্পাদনা করলে সার্ভারে MFA চালু হয় না

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

অনুরোধটি কেবল প্রমাণ করে যে ক্লায়েন্ট জিজ্ঞেস করেছে, এর বেশি নয়

.ovpn ফাইলটি ক্লায়েন্ট-পক্ষের একটি নথি। এটি ক্লায়েন্টকে শংসাপত্র চাইতে, ক্যাশ করতে বা ক্যাশ করা বন্ধ করতে বলতে পারে। এটি কোনো ব্যবহারকারী নিবন্ধন করতে পারে না, PAM মডিউল ইনস্টল করতে পারে না, বা সার্ভারকে এমন দ্বিতীয় ফ্যাক্টর দাবি করতে বাধ্য করতে পারে না যা সে এখন যাচাই করে না।

ফোনে একটি প্রমাণীকরণ অ্যাপ ইনস্টল করলেও সেই সম্পর্ক তৈরি হয় না। Google Authenticator PAM প্রকল্পটি একটি OTP যাচাই উপাদান যা OpenVPN-এর পেছনে থাকতে পারে; এটি আমদানি করা প্রোফাইলে Google অ্যাকাউন্ট লগইন জুড়ে দেওয়ার উপায় নয়।

নিবন্ধনই সেই অংশ যা একটি প্রোফাইল করতে পারে না

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

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

PAM-ভিত্তিক ডিজাইনে প্রতিটি VPN ব্যবহারকারীর জন্য আলাদা Unix অ্যাকাউন্ট তৈরি করা আবশ্যক নয়। মডিউলের ডকুমেন্টেশন বিকল্প গোপন পথ এবং ফাইল-প্রবেশের জন্য একটি নিবেদিত অ্যাকাউন্ট সমর্থন করে, যা ফাইলসিস্টেম পরিচয়, যাচাই করা লগইন পরিচয় নয়।

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

PAM স্ট্যাক পড়ে দেখুন আসলে কী দরকার

account required pam_permit.so-এর মতো একটি লাইন অ্যাকাউন্ট যোগ্যতা প্রয়োগ করে না এবং কোনো ফ্যাক্টর যোগ করে না। এটি সেই PAM অ্যাকাউন্ট-ব্যবস্থাপনা ধাপটির অনুমতি দেয়, যা আপনার ব্যবহারকারীদের নয়, একটি ধাপ সম্পর্কে বক্তব্য।

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

ক্লায়েন্টের মিথস্ক্রিয়াকে সার্ভারের ডিজাইনের সাথে মেলান

auth-user-pass

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

ক্লায়েন্ট একটি ফিল্ড দেখায় বলে পাসওয়ার্ডে কোড জুড়ে দেবেন না। এটি কেবল সেখানেই কাজ করে যেখানে সার্ভারের প্লাগইন ঠিক সেই বিন্যাস প্রত্যাশা করে, এবং অন্য সব জায়গায় এটি বিভ্রান্তিকরভাবে ব্যর্থ হয়।

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

পুনঃসংযোগ, টোকেন এবং যে পরীক্ষা বিষয়টি নিষ্পত্তি করে

প্রথম সফল লগইনের পরে কী হবে তা পরিকল্পনা করুন। আগে গৃহীত কোড পরবর্তী প্রমাণীকরণে মেয়াদোত্তীর্ণ বা পুনরাবৃত্তি হিসেবে প্রত্যাখ্যাত হতে পারে। auth-nocache শংসাপত্র ধরে রাখা নিয়ন্ত্রণ করে এবং MFA ইনস্টল করে না, আর reneg-sec 0 ফোরাম থ্রেডে যতবারই দেখা যাক, TOTP সমর্থনের সংজ্ঞা নয়।

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

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