OpenVPN username-as-common-name: আপনার CN যাচাই কেন খালি আসে
common_name-এর সঙ্গে username তুলনা করা একটি client-connect স্ক্রিপ্ট একটি নামকে তার নিজের সঙ্গেই তুলনা করতে পারে। প্রতিস্থাপন চলার আগেই অ্যাকাউন্টের সঙ্গে সার্টিফিকেট বেঁধে দিন।
আপনি একটি client-connect স্ক্রিপ্ট যোগ করেন যা এমন প্রতিটি সংযোগ প্রত্যাখ্যান করে যেখানে common_name username থেকে আলাদা, এবং এটি সার্টিফিকেট ও অ্যাকাউন্টের মধ্যে একধরনের বাঁধন বলে মনে হয়। username-as-common-name চালু থাকা কোনো সার্ভারে স্ক্রিপ্টটি চালু হওয়ার সময়েই ওই তুলনাটি তার অর্থ হারিয়ে ফেলেছে। দুটি মানই একই স্ট্রিং, তাই ভিন্ন কোনো ব্যক্তির জন্য ইস্যু করা সার্টিফিকেটেও পরীক্ষাটি পাশ করে।
স্ক্রিপ্টটি খারাপভাবে লেখা, তাই যাচাইটি ভুল নয়। যাচাইটি ভুল কারণ এটি যে মানটি পড়ে, সেটি একই সংযোগের আগের ধাপেই প্রতিস্থাপিত হয়ে গিয়েছিল।
তুলনাটি কী প্রমাণ করে বলে মনে হয়
সার্টিফিকেট প্রমাণীকরণ আর পাসওয়ার্ড প্রমাণীকরণ আলাদা আলাদা প্রমাণ, এবং সার্ভার দুটোই দাবি করতে পারে, এটা না দাবি করেই যে তারা একই ব্যক্তির। ফাঁকটি বাস্তব: একটি বৈধ ডিভাইস সার্টিফিকেটের সঙ্গে যেকোনো বৈধ অ্যাকাউন্ট এক জিনিস, আর সেই ডিভাইস সার্টিফিকেটের সঙ্গে নাম ধরে একটি নির্দিষ্ট অ্যাকাউন্ট অন্য জিনিস। common_name-এর সঙ্গে username তুলনা করা একটি স্ক্রিপ্ট দুটির মধ্যে হারানো যোগসূত্রের মতো শোনায়। common_name যদি এখনও সার্টিফিকেট যা বলেছে সেটাই বোঝাত, তাহলে তা-ই হতো।
তা হয় কি না, নির্ভর করে একটি সার্ভার অপশনের উপর, আর সেই অপশনটি সাধারণত অসম্পর্কিত কোনো কারণে চালু করা হয়, যেমন প্রতি-ব্যবহারকারীর কনফিগারেশন ফাইলের নাম দেওয়া সহজ করতে।
username-as-common-name নামটির সঙ্গে যা করে
username-as-common-name চালু থাকলে, ব্যবহারকারীর নাম ও পাসওয়ার্ড যাচাই হওয়ার পর OpenVPN সার্টিফিকেটের কমন নেমের জায়গায় যাচাই করা ব্যবহারকারীর নাম বসিয়ে দেয়। ওই যাচাইয়ের সময় চলা যাচাই হুক এখনও সার্টিফিকেটের কমন নেম পায়, কারণ প্রতিস্থাপনটি তখনও ঘটেনি। এর পরের সব কিছু, client-connect সহ, ব্যবহারকারীর নামটিই দেখে। তাই পরের কলব্যাক একই পরিচয় দুবার পায় এবং উপস্থাপিত সার্টিফিকেটের সঙ্গে তার তুলনা করতে পারে না।
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
একটি উদাহরণ সংযোগ ধরা যাক: bob-device-এর জন্য ইস্যু করা সার্টিফিকেট, alice হিসেবে সফল ডিরেক্টরি লগইন, আর অপশনটি চালু। যাচাইয়ের ধাপটি এখনও দুটি ভিন্ন স্ট্রিং দেখতে পায়। সংযোগের ধাপটি alice আর alice দেখে।
উদাহরণটি দেখায় কেন তুলনাটি খালি। এটি দেখায় না যে সংযোগটি নাহলে গৃহীত হতো, কারণ সার্টিফিকেট যাচাই ও পাসওয়ার্ড যাচাই এখনও নিজের মতো চলে।
যেখানে দুই পরিচয়ই এখনও আছে সেখানেই বাঁধনটি রাখুন
নিয়মটি এমন একটি ধাপে প্রয়োগ করতে হবে যা সার্টিফিকেটের পরিচয় ও অ্যাকাউন্ট একসঙ্গে দেখে, ব্যবহারিক অর্থে তা হলো ব্যবহারকারীর নাম ও পাসওয়ার্ড যাচাই হুক বা সেখানে লোড করা একটি প্লাগইন। যে সমর্থিত প্লাগইন ইতিমধ্যে পাসওয়ার্ড যাচাই করে, সেটিই সাধারণত জোড়া বাঁধার নিয়ম যোগ করার সঠিক জায়গা, কারণ সেটিকে নাম-তুলনার সাথে বদলে দিলে পাসওয়ার্ড যাচাই পুরোপুরি বাদ পড়বে।
কোড লেখার আগেই ম্যাপিংটি ঠিক করুন, কারণ সমতা খুব কম ক্ষেত্রেই আসল নীতি। একটি সার্টিফিকেট প্রায়ই একটি ডিভাইস চেনায়, আর লগইন চেনায় একজন ব্যক্তিকে, এবং একটি ডিভাইস বৈধভাবে একাধিক মানুষকে সেবা দিতে পারে। সম্পর্কটি এমন এক রূপে রাখুন যার ইস্যু আপনার নিয়ন্ত্রণে, আর ঠিক করুন নতুন নাম দেওয়া, পুনরায় ইস্যু করা এবং ডোমেইন-যুক্ত নামের ক্ষেত্রে কী হবে। ডিরেক্টরি না বুঝেই ডোমেইন উপসর্গ ছোট হাতের করা বা সরিয়ে ফেলা দুটি অ্যাকাউন্ট মিলিয়ে দিতে পারে, যেগুলো আলাদা থাকার কথা ছিল।
মনে রাখুন, অপশনটি কোন প্রতি-ক্লায়েন্ট কনফিগারেশন প্রযোজ্য হবে তাও বদলে দেয়, কারণ client-config-dir কমন নেম দিয়ে কী-করা হয়।
দুটি বৈধ ক্রেডেনশিয়াল দিয়ে জোড়াটি পরীক্ষা করুন
আপনার নীতি যে জোড়াটি অনুমোদন করে সেটি দিয়ে শুরু করুন এবং দেখুন সংযোগ হয় কি না। তারপর একই বৈধ সার্টিফিকেট অন্য একটি, তবে অন্যভাবে বৈধ অ্যাকাউন্টের সঙ্গে উপস্থাপন করুন: সেই চেষ্টা অবশ্যই ব্যর্থ হতে হবে, এবং ব্যর্থ হতে হবে জোড়া বাঁধার নিয়মের কারণে, ভুল টাইপ করা পাসওয়ার্ডের কারণে নয়। ভুল পাসওয়ার্ড প্রমাণ করে পাসওয়ার্ড যাচাই কাজ করে, আর সার্টিফিকেট-অ্যাকাউন্ট নিয়ম সম্পর্কে কিছুই বলে না।
সার্টিফিকেট না থাকা ও অবৈধ সার্টিফিকেটের পথগুলিও পরীক্ষা করুন, এবং সার্ভার প্রতি-ক্লায়েন্ট সেটিংসের জন্য কোন পরিচয় ব্যবহার করে তা নিশ্চিত করুন। তুলনাটি কাজ করানোর একমাত্র উপায় যদি username-as-common-name বন্ধ করা হয়, তাহলে আগে ওই পরিবর্তনের দাম হিসাব করুন, কারণ এটি প্রতিটি ক্লায়েন্টের কনফিগারেশন খোঁজাকে আবার সার্টিফিকেটের নামের দিকে ফিরিয়ে দেয়।