কেন সার্ভার কী এবং ব্যবহারকারীর পরিচয়পত্রের আলাদা মালিক দরকার

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

দুটি গোপন তথ্য, দুজন আলাদা মালিক

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

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

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

বিচ্ছেদ ঠিক করার তিনটি প্রশ্ন

জিজ্ঞাসা করুন কে গোপন তথ্যটি পড়তে পারবে, ফাঁস হলে আক্রমণকারী কী করতে পারবে, আর সমাধানটি একটি বাতিলকরণ না সেবার পুনর্নির্মাণ।

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

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

একজন ক্লায়েন্টের আসলে যা দরকার

একজন ক্লায়েন্টের দরকার প্রকাশ্য সার্টিফিকেট বা প্রকাশ্য সহকর্মী কী, যে CA উপাদান বা ফিঙ্গারপ্রিন্টে তার বিশ্বাস করা উচিত, তার নিজের ব্যক্তিগত কী এবং প্রান্তবিন্দুর বিবরণ। সেই তালিকায় গেটওয়ের ব্যক্তিগত পরিচয়ের কিছুই নেই।

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

গেটওয়েতে হাত না দিয়ে একজন ব্যবহারকারীকে বাতিল করুন

যেহেতু ব্যবহারকারীর পরিচয় আলাদাভাবে দেওয়া হয়, সেগুলো আলাদাভাবে প্রত্যাহার করা যায়। সার্টিফিকেটভিত্তিক স্থাপনা ক্লায়েন্ট সার্টিফিকেট বাতিল করে আর একটি হালনাগাদ বাতিলকরণ তালিকা প্রকাশ করে; WireGuard স্থাপনা সার্ভার কনফিগারেশন থেকে সহকর্মীর এন্ট্রি সরিয়ে দেয়। এই কাজগুলোর কোনোটিই গেটওয়ের নিজের কী বদলায় না।

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

নিচের কমান্ডগুলো একটি ক্লায়েন্ট সার্টিফিকেট পরীক্ষা করে এবং তারপর OpenSSL-ধাঁচের একটি কর্তৃপক্ষের মাধ্যমে তা বাতিল করে, আর easy-rsa ঠিক এই প্রবাহটিই মোড়কে দেয়:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

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

ব্যাকআপগুলোকে গোপন তথ্যের মতোই আলাদা রাখুন

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

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