সংশোধন: OpenVPN স্ট্যান্ডার্ড ইনপুট থেকে Auth ব্যবহারকারীর নাম পড়তে পারেনি

could not read Auth username from stdin প্রমাণীকরণের সমস্যার মতো দেখায়, কিন্তু তা নয়। OpenVPN স্ট্যান্ডার্ড ইনপুটে ব্যবহারকারীর নাম চাইতে চেয়েছিল, কিছু পঠনযোগ্য পায়নি, এবং সার্ভারের সঙ্গে যোগাযোগ করার আগেই থেমে গেছে। অ্যাকাউন্টটি সম্পূর্ণ বৈধ হতে পারে; প্রক্রিয়াটির জিজ্ঞাসা করার মতো কেউ নেই।

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

ত্রুটিটিকে স্থানীয় ইনপুট ব্যর্থতা হিসেবে পড়ুন

যখন auth-user-pass কোনো ফাইল আর্গুমেন্ট ছাড়া আসে, তখন ক্লায়েন্ট প্রম্পট আশা করে। ইন্টারঅ্যাকটিভ শেলে সেই প্রম্পট কাজ করে কারণ প্রক্রিয়ার একটি টার্মিনাল থাকে। systemd, cron কাজ বা কনটেইনারের অধীনে স্ট্যান্ডার্ড ইনপুট সাধারণত খালি থাকে, এবং পাঠটি আপনি যে ত্রুটি দেখছেন তা নিয়েই সঙ্গে সঙ্গে ফিরে আসে।

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

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

পরিষেবাকে একটি সমর্থিত ক্রেডেনশিয়াল উৎস দিন

সমর্থিত আন-অ্যাটেনডেড উৎস হলো একটি ক্রেডেনশিয়াল ফাইল, যা আর্গুমেন্ট হিসেবে auth-user-pass-কে দেওয়া হয়। ফাইলটি সাধারণ টেক্সট হিসেবে পড়া হয়: প্রথম লাইন ব্যবহারকারীর নাম, দ্বিতীয়টি পাসওয়ার্ড। এটিকে একটি পরম পথ দিয়ে দেখান, যেমন /etc/openvpn/client/creds , যাতে পরিষেবা অ্যাকাউন্টের কার্যকারী ডিরেক্টরি নির্দেশের অর্থ বদলাতে না পারে।

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

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

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

কেন script-security সাহায্য করবে না

script-security নিয়ন্ত্রণ করে ক্লায়েন্ট স্ক্রিপ্ট চালাতে পারবে কি না এবং তাদের কতটা দিতে পারবে, যার মধ্যে পরিবেশ চলক দিয়ে স্ক্রিপ্টকে পাসওয়ার্ড দেওয়া যায় কি না তাও আছে। ব্যবহারকারীর নাম ও পাসওয়ার্ড কোথা থেকে আসছে সে সম্পর্কে এর কিছু বলার নেই।

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

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

ক্লায়েন্ট ফাইলটি পড়ার পরে পরবর্তী ধাপ যাচাই করুন

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

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

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

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