duplicate-cn দুটি ডিভাইসকে এক পরিচয় দেয়, দুটি নয়

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

মিথ: দ্বিতীয় সেশন মানেই দ্বিতীয় পরিচয়

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

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

সবকিছু ঠিকঠাক চলার সময় এই পার্থক্য অদৃশ্য থাকে। দুটি ডিভাইসকে আলাদা করে চেনার দরকার হওয়ার মুহূর্তেই এটি খুব দৃশ্যমান হয়ে ওঠে — আর সেটি সাধারণত সেই দিন, যেদিন তাদের একটি হারিয়ে যায়।

দুটি সেশন একই নাম ভাগ করলে আসলে কী বদলায়

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

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

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

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

যে স্থির ঠিকানাটি আপনি বরাদ্দ করেছেন বলে ভেবেছিলেন

প্রতি-ক্লায়েন্ট কনফিগারেশন নাম দিয়ে খোঁজা হয়, আর এখানেই ফাঁদ। সাধারণ নামের অনুকরণে নামকরণ করা client-config-dir ফাইল ওই নাম ব্যবহার করা প্রতিটি ডিভাইসে প্রযোজ্য হয়, তাই তার ভেতরের ifconfig-push দুটি ডিভাইসকেই একই টানেল ঠিকানা দেয়। দ্বিতীয় সেশনটি হয় প্রতিষ্ঠিত হতে ব্যর্থ হয়, নয়তো এমনভাবে সংঘর্ষ করে যা রাউটিং ত্রুটির মতো দেখায়।

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

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

অপসারণের সময় একটি ভাগ করা পরিচয় যা করতে পারে না

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

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

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

কখন ভাগ করা ঠিক, এবং কীভাবে তা সীমিত করবেন

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

আলাদা ঠিকানা, আলাদা লগ বা আলাদা অপসারণ দরকার — এমন সবকিছুর জন্য স্বাভাবিক নথিভুক্তি পথে আলাদা সার্টিফিকেট ইস্যু করুন। এটি প্রতিটি পরবর্তী সিস্টেমকে আলাদা একটি বস্তু দেয় যার উপর নির্ভর করা যায়, আর অপশনটির গুরুত্ব থাকে না, কারণ নামগুলো আগেই অনন্য।

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