রানবুক: দুটি OpenVPN গ্রাহককে আলাদাভাবে অনবোর্ড করা

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

প্রত্যেক গ্রাহকের জন্য একটি সম্পূর্ণ সম্পদ কার্ড নির্ধারণ করুন

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

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

ট্রাস্ট উপকরণ প্রত্যেক গ্রাহকের ভেতরে রাখুন

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

সার্ভারের নিজস্ব প্রাইভেট কী প্রত্যেক গ্রাহকের জন্য একটি সুরক্ষিত ফাইলে থাকা উচিত, কনফিগারেশনের সঙ্গে প্রতিলিপি হওয়া টেমপ্লেট ডিরেক্টরিতে নয়।

প্রসেসের মতো নেটওয়ার্কও আলাদা করুন

দুটি পোর্টে দুটি প্রসেস আলাদা না করলে এখনও একটি হোস্ট ও একটি রাউটিং টেবিল ভাগ করে। নকশায় ভরসা করার আগে কী শুনছে তা নিশ্চিত করুন।

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

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

হস্তান্তরের আগে প্রত্যাহার সরবরাহ করুন

প্রত্যাহারের সরবরাহ পথ না থাকলে একটি সার্টিফিকেট স্থাপন অসম্পূর্ণ। অনবোর্ডিংয়ের অংশ হিসেবে CRL-এর ইস্যুকারী ও বৈধতার সময়সীমা যাচাই করুন।

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

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

তারপর গ্রহণযোগ্যতা জোড়াটি চালান: অনুমোদিত একটি ক্লায়েন্ট নিজের সার্ভিসে পৌঁছায়, আর A-এর ক্রেডেনশিয়াল B-এর লিসেনার প্রত্যাখ্যান করে। এটাই সীমান্ত, একটি পরীক্ষা হিসেবে প্রকাশ করা।