ক্লায়েন্ট সংযোগ করার আগেই দুটি নাম আসে: ল্যাপটপের ফাইলনাম (nuc.ovpn) এবং সার্ভার ক্রেডেনশিয়াল থেকে যে পরিচয় বের করে। client-config-dir অনুসন্ধান দ্বিতীয়টি ব্যবহার করে। ক্লায়েন্টে প্রোফাইলের নাম বদলানো, বা সার্ভারের ফাইলে .conf যোগ করা, সার্ভার কোন ফাইল খুলবে তা বদলায় না।

কাজের তুলনা হলো «আমি কোন নাম ব্যবহার করেছি» নয়, «সার্ভার কোন নিয়ম প্রয়োগ করছে», কারণ সার্টিফিকেট প্রমাণীকরণ এবং ব্যবহারকারীনাম/পাসওয়ার্ড প্রমাণীকরণ একই লগইন থেকে ভিন্ন কার্যকর নাম তৈরি করতে পারে।

প্রোফাইল নাম বনাম সার্টিফিকেটের কমন নেম

ডিফল্ট সার্টিফিকেটভিত্তিক সেটআপে সার্ভার X.509 কমন নেম নেয় এবং client-config-dir-এর ভিতরে ঠিক সেই নামের ফাইল খোঁজে। যে প্রোফাইলের নাম nuc.ovpn আর সার্টিফিকেটে লেখা tester, সেটি /etc/openvpn/server/ccd/tester এ মিলে যায়। ক্লায়েন্ট ফাইলনাম কখনও হিসাবের মধ্যে আসে না। অসঙ্গতি লুকিয়ে থাকার প্রথম জায়গা এটিই।

তাই যত্নে নাম দেওয়া প্রোফাইলে ভরা একটি ডিরেক্টরি প্রতিবারই মিস করতে পারে। ফাইলটি subject দিয়ে, ইমেইল ঠিকানা দিয়ে বা GUI-তে দেখানো নাম দিয়ে মেলানো হয় না; মেলানো হয় কমন নেম স্ট্রিং দিয়ে।

কেস-সংবেদনশীল ফাইলসিস্টেমে Tester আর tester দুটি আলাদা ফাইল, এবং কেবল একটি খোলা হয়। কমন নেম দেখুন ক্লায়েন্ট আসলে যে সার্টিফিকেট উপস্থাপন করে সেখান থেকে, আপনার নোটের কপি থেকে নয়।

username-as-common-name নিয়মটি উল্টে দেয়

সার্ভার যখন username-as-common-name সহ ব্যবহারকারীনাম/পাসওয়ার্ড প্রমাণীকরণ চালায়, তখন এই অনুসন্ধানের জন্য প্রমাণিত ব্যবহারকারীনাম সার্টিফিকেটের কমন নেমকে প্রতিস্থাপন করে।

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

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

সার্ভার কী পড়ে, আর কী নিঃশব্দে এড়িয়ে যায়

দুটি ছোট পার্থক্য ঠিক করে ফাইল বাছা হবে কি না। প্রথমটি হলো যোগ করা এক্সটেনশন। দ্বিতীয়টি নামের মধ্যে একটি এলোমেলো অক্ষর।

OpenVPN যে নাম খোঁজে তার সঙ্গে .conf যোগ করে না, তাই tester.conf tester-এর সঙ্গে মেলে না। যে এডিটর এক্সটেনশন লুকায়, সেটি তালিকায় সঠিক দেখানো কিন্তু কখনও না মেলা ফাইল রেখে যেতে পারে।

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

সঠিক ফাইলনাম বিষয়বস্তু যাচাই করে না

নির্বাচন ও বিষয়বস্তু আলাদা ব্যর্থতা। সঠিক ফাইল খোলার পরেও তার নির্দেশনাগুলো সেই ক্লায়েন্টের জন্য বৈধ হতে হবে।

ifconfig-push এমন ঠিকানা দিতে হবে যা টপোলজি সত্যিই ব্যবহার করতে পারে, আর iroute কেবল সেই ক্লায়েন্টের পেছনের রাউটেড সাবনেটের জন্যই অর্থবহ।

এক পরিচয়, একাধিক ডিভাইস

একই কমন নেম উপস্থাপন করা দুটি ল্যাপটপ একই ফাইল বেছে নেয় এবং একই ক্লায়েন্ট-নির্দিষ্ট সেটিং পায়। আলাদা ঠিকানা বা আলাদা প্রত্যাহার দরকার হলে আলাদা পরিচয় দরকার, এক ফাইলের দুটি কপি নয়।

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

সম্পর্কিত নিবন্ধ