OpenVPN CA-র সাইনিং কী /etc/openvpn-এর বাইরে রাখুন

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

CA-র কর্মক্ষেত্রে কী থাকে

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

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

পাবলিক CA সার্টিফিকেট আলাদা। এটি বিতরণের জন্যই, এবং ক্লায়েন্ট ও সার্ভার একে অপরকে যাচাই করতে এটি ব্যবহার করে।

চালু হওয়ার সময় ডেমন কী পড়ে

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

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

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

তৃতীয় লাইনটাই মানুষ বাদ দেয়। এটি ডেমনর নিজের অ্যাকাউন্টকেই জিজ্ঞেস করে সে কী পড়তে পারে কি না, আর বিশেষাধিকার ছাড়ার পরে এটিই প্রশ্নের একমাত্র রূপ যা গুরুত্বপূর্ণ। root হিসেবে শূন্য এক্সিট কোড ছাড়ার পরে কী ঘটে সে সম্পর্কে কিছুই বলে না।

যেকোনো অনুমতি বদলানোর আগে দুটি ব্যর্থতার পথ আলাদা করা উচিত। সাইনিং ব্যর্থতা PKI ডিরেক্টরি, তার মূল ডিরেক্টরিগুলোর সার্চ অনুমতি এবং ইস্যুকারী চালানো অ্যাকাউন্টের দিকে ইঙ্গিত করে। স্টার্টআপ ব্যর্থতা ইউনিট, তার কাজের ডিরেক্টরি এবং সার্ভার কনফিগারেশনে নামানো পথগুলোর দিকে ইঙ্গিত করে। গোটা গাছকে সবার পাঠযোগ্য করা এর কোনোটিই ঠিক করে না, বরং যে সীমা দুটিই নির্ভর করে তা সরিয়ে দেয়।

কেন CA কী সার্ভারে কপি করলে পরে ব্যর্থ হয়

কপিটি সাধারণত ডিবাগিংয়ের পদক্ষেপ হিসেবে শুরু হয়: কেউ VPN হোস্টে একটি ক্লায়েন্ট নবায়ন করতে চায়, তাই CA কী /etc/openvpn-এ গিয়ে পড়ে এবং নবায়ন কাজ করে। তাৎক্ষণিক কাজ সফল হয়, আর সীমাটি থাকে না।

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

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

অ্যাকাউন্ট, ডিরেক্টরি, ব্যাকআপ

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

বাতিলের পরে সার্ভার কনফিগারেশনে নামানো CRL ফাইল হালনাগাদ করুন, তারপর সেবা রিলোড করুন যাতে নতুন সংযোগ তা পড়ে। Easy-RSA ডকুমেন্টেশন কর্মক্ষেত্রের বিন্যাস ও সাইনিং কর্মপ্রবাহ কভার করে; এর চারপাশের মালিকানা নিয়ম আপনার হোস্ট সম্পর্কে সিদ্ধান্তই থাকে। সেবা কী লোড করেছে তা openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate দিয়ে নিশ্চিত করুন, রিলোড এটি নিয়েছে ধরে নেওয়ার বদলে।

বিভাজন প্রমাণ করে এমন পরীক্ষা

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

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