iPad-এর কি নিজস্ব VPN ক্লায়েন্ট সার্টিফিকেট প্রয়োজন?

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

একই ইস্যুয়ার, আলাদা পরিচয়

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

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

যখন দ্বিতীয় সার্টিফিকেট বেশি ব্যয়বহুল

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

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

ডিভাইস নথিভুক্ত করুন, কী কপি করবেন না

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

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

উত্তর দেওয়ার আগে প্রত্যাহার পরীক্ষা করুন

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

openssl pkcs12 -in client.p12 -info -noout
openssl x509 -in client.pem -noout -subject -issuer -serial -dates
openssl verify -CAfile ca.pem client.pem

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

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