OpenVPN-এর auth-user-pass-verify স্ক্রিপ্ট: এক্সিট কোড ঠিকভাবে দিন

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

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

হুক যে তিনটি স্ট্যাটাস ফেরত দিতে পারে

auth-user-pass-verify-এর জন্য OpenVPN 2.6 ম্যানুয়াল এক্সিট কোড 0-কে গ্রহণ, 1-কে প্রত্যাখ্যান এবং 2-কে বিলম্বিত প্রমাণীকরণ হিসেবে সংজ্ঞায়িত করে। সার্ভার বোঝে ঠিক এই তিনটি উত্তর, এবং প্রতিটির সংযোগের ওপর ভিন্ন পরিণতি আছে। যে স্ক্রিপ্ট তার শেষ কমান্ডের স্ট্যাটাস নিয়ে বেরিয়ে যায়, সে কার্যত একটি লগিং কল বা ক্লিনআপ ধাপকে ভোট দিতে দিয়েছে। প্রতিটি শাখায় স্ট্যাটাস স্পষ্টভাবে লিখুন, সেই শাখাগুলোও যেগুলো কখনো ভেরিফায়ারে পৌঁছায়নি।

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

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

ক্রেডেনশিয়াল ফাইল ঠিক যেমন লেখা আছে তেমনভাবে পড়ুন

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

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

শ্রেণিবদ্ধ করা যায় না এমন উত্তরের অর্থ নির্ধারণ করুন

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

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

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

রায় যাচাই করুন, ছাপা লাইন নয়

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

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

ভেরিফায়ারের ফলাফল থেকে এক্সিট স্ট্যাটাসে ম্যাপিংটি রিপোজিটরিতে স্ক্রিপ্টের পাশে রাখুন, যাতে পরের প্রকৌশলী কোড উল্টো-প্রকৌশল না করেই চুক্তিটি পড়তে পারেন।