CA পুনর্নির্মাণ ছাড়াই একটি VPN ক্লায়েন্ট যোগ করা: কখন এবং কীভাবে

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

পুনর্নির্মাণ আসলে কী ধ্বংস করে

PKI পুনরায় আরম্ভ করলে ডিরেক্টরিটি একটি ফাঁকা কাঠামোয় বদলে যায়: নতুন CA কী ও সার্টিফিকেট, খালি ইস্যু ডেটাবেস, নতুন সিরিয়াল কাউন্টার। ক্লায়েন্টরা নীরবে এটি অনুসরণ করে না। তাদের প্রোফাইল পুরনো CA-তে পিন করা থাকে, তাই প্রতিটি বিদ্যমান ডিভাইসকে আবার এনরোল করতে হয়, আর যে ডিভাইসে পৌঁছানো যায় না সেটি হাতে এনরোল করতে হয় বা বদলে ফেলতে হয়।

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

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

প্রথম শর্ত: ইস্যুয়ারের অবস্থা কি এখনও নাগালে আছে?

কিছু সিদ্ধান্ত নেওয়ার আগে সার্ভার আসলে কোন ডিরেক্টরিকে বিশ্বাস করে তা খুঁজে বের করুন। সার্ভার যে সার্টিফিকেটকে নিজের CA হিসেবে উপস্থাপন করে, তা ফাইলের নাম নয়, ফিঙ্গারপ্রিন্ট দিয়ে আপনার PKI ডিরেক্টরির সার্টিফিকেটের সঙ্গে মিলিয়ে দেখুন:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

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

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

দ্বিতীয় শর্ত: নতুন প্রাইভেট কী কার হাতে থাকবে?

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

বিদ্যমান CA-র বিপরীতে Easy-RSA 3 ব্যবহার করলে অনুরোধ আমদানি করা ও সাইন করা দুটি কমান্ডের কাজ:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

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

তৃতীয় শর্ত: সার্ভারের কি সার্টিফিকেটের বেশি কিছু দরকার?

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

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

ক্রমবর্ধমান পদ্ধতি, এবং পুনর্নির্মাণের যুক্তি

পার্শ্বক্ষতি ছাড়াই একটি ডিভাইস যোগ করার ক্রমটি এমন: ফিঙ্গারপ্রিন্ট দিয়ে ইস্যুয়ার নিশ্চিত করুন, PKI ডিরেক্টরির একটি নতুন ব্যাকআপ নিন, ক্লায়েন্ট ভূমিকার জন্য অনুরোধটি আমদানি করে সাইন করুন, অনুমোদিত চ্যানেলের মাধ্যমে সার্টিফিকেটটি তার চেইনসহ পৌঁছে দিন, তারপর ব্যবহারকারী সংযুক্ত হওয়ার আগে যাচাই করুন:

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

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

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