শেয়ার করা CA, আলাদা দরজা: প্রতিটি ভর্তি-ফাইলে একটিমাত্র সেবা

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

বিশ্বস্ত শৃঙ্খল সেবার সদস্যপদ সম্পর্কে কিছুই বলে না

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

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

ঐচ্ছিক ওভাররাইডকে ভর্তির গেটে পরিণত করুন

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

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

কমিউনিটি সংস্করণের OpenVPN 2.6 ccd-exclusive এ নিজের ম্যানুয়াল পৃষ্ঠায় ঠিক এই শর্ত হিসেবেই নথিভুক্ত করে, এবং নামযুক্ত ফাইলের অনুসন্ধান কার্যকর ক্লায়েন্ট পরিচয়ের উপর নির্ভর করে। অন্যান্য বিল্ড ও পণ্য-পরিচালিত সার্ভার ভিন্ন হতে পারে, তাই অন্যত্র একই অর্থবৃত্তির উপর নির্ভর করার আগে ইনস্টল করা সংস্করণ নিশ্চিত করুন।

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

প্রতি সেবায় একটি ডিরেক্টরি, একটি শেয়ার করা তালিকা নয়

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

DEFAULT এন্ট্রি হল সেই ক্ষেত্র যা মানুষকে বিভ্রান্ত করে। নামযুক্ত ফাইল না পাওয়া গেলে এটি ফলব্যাক সেটিংস দেয়, কিন্তু এটি গেটের দাবি করা নামযুক্ত ফাইল নয়, তাই এটি একা একটি ক্লায়েন্টকে ভর্তি করতে পারে না। এমন ক্লায়েন্ট পরীক্ষা করুন যার কোনো এন্ট্রি নেই এবং প্রত্যাখ্যান নিশ্চিত করুন; যদি সেই ক্লায়েন্ট ভর্তি হয়, তবে ফলব্যাক প্রয়োগ হচ্ছে এবং ccd-exclusive ওই দৃষ্টান্তে কার্যকর নয়।

কার্যকর পরিচয়ই নির্ধারণ করে কোন ফাইল পড়া হবে

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

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

প্রত্যাখ্যান, ভর্তি ও রদ আলাদা আলাদা পর্যবেক্ষণ করুন

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

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

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