OpenVPN-এ RADIUS যুক্ত করা: প্লাগইন নাকি স্ক্রিপ্ট হুক?

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

মিথ: প্লাগইনটিই সমর্থিত পথ

প্লাগইন একটি শেয়ার্ড অবজেক্ট যা OpenVPN প্রসেসে লোড হয়, তাই এটি সেই প্রসেসের দেওয়া ইন্টারফেসের সঙ্গে মিলতে হবে। বিল্ড বদলায়, প্যাকেজিং বদলায়, এবং পুরোনো ইন্টারফেসের জন্য কম্পাইল করা লাইব্রেরি লোড হতে সোজা অস্বীকার করে। সার্ভার কনফিগারেশনের কিছুই সেই ফাঁক পূরণ করতে পারে না, তাই "শুধু radiusplugin ইনস্টল করুন" পরামর্শ শেষ হয় এমন সার্ভারে যা চালু হয় না।

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

কোনো পদ্ধতিই গঠনগতভাবে বেশি নিরাপদ নয়। একটি ডেমনোর ভিতরে বিদেশি কোড চালায়; অন্যটি ক্রেডেনশিয়াল হাতে নিয়ে আপনার কোড তার পাশে চালায়। সঠিক প্রশ্ন হলো এই দুটি ঝুঁকির মধ্যে কোনটি আপনি সত্যিই পরিচালনা করতে পারেন।

প্লাগইন কী একসাথে বেঁধেছিল

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

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

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

স্ক্রিপ্ট হুক আসলে কীসের উপর ভরসা করে

হুকটি auth-user-pass-verify এবং একটি ডেলিভারি ব্যবস্থার মাধ্যমে কনফিগার করা হয়: পরিবেশ ভেরিয়েবল বা একটি অস্থায়ী ফাইল। পরিবেশ রূপে OpenVPN script-security 3 দাবি করে, যা স্ক্রিপ্টে পাসওয়ার্ড প্রকাশের অনুমতি দেওয়া নথিভুক্ত স্তর। সেই স্তরটি ডিফল্টের ইচ্ছাকৃত দুর্বলতা, এবং এটিকে যুক্তিসহ অনুমতিপত্র হিসেবে গণ্য করা উচিত।

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

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

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

এক্সিট কোড ঠিক করে আপনি খোলা অবস্থায় ব্যর্থ হবেন কি না

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

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

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

সার্টিফিকেট চলে গেলে আপনি কী হারান

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

কন্ট্রোল-চ্যানেল সুরক্ষা রাখুন যাতে অ-প্রমাণিত পিয়ার হ্যান্ডশেক প্রোব বা ফ্লাড করতে না পারে, এবং username-as-common-name ব্যবহার করুন যখন প্রতি-ব্যবহারকারী কনফিগারেশন কমন নেমের উপর নির্ভর করে। ম্যানেজড গেটওয়ে প্রায়ই এটি ভিন্নভাবে সমাধান করে, RADIUS-এর সঙ্গে EAP-TLS কথা বলা গেটওয়েতে সার্টিফিকেট প্রমাণীকরণ শেষ করে, এবং সেক্ষেত্রে এই সার্ভার নির্দেশনার কোনোটিই প্রযোজ্য নয়। আপনার নিজের প্ল্যাটফর্ম যে মডেল নথিভুক্ত করে তা কপি করুন, প্রতিবেশী পণ্যেরটি নয়। গুরুত্বপূর্ণ নির্দেশনাগুলো যথেষ্ট আলাদা যে সেগুলো মেশালে এমন কনফিগারেশন তৈরি হয় যা পার্স হয় এবং তারপর কাউকে প্রমাণীকরণ করে না।