ক্লায়েন্ট সার্টিফিকেট ছাড়া OpenVPN: সার্ভার নীতি, প্রোফাইল নয়

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

প্রোফাইল নীতিটি নয়

Community OpenVPN 2.6 ক্লায়েন্ট সার্টিফিকেট বাধ্যতামূলক নিয়ে আসে, কারণ verify-client-cert ডিফল্টভাবে require। এটিকে none-এ সেট করাই সার্টিফিকেটের দাবি থামায় এবং ক্লায়েন্ট প্রমাণীকরণ সার্ভার ইতিমধ্যে যে ব্যবহারকারীনাম ও পাসওয়ার্ড ব্যবস্থা চালায় তার হাতে ছেড়ে দেয়। পুরোনো নির্দেশিকাগুলো client-cert-not-required-এর দিকে হাত বাড়ায়, একই ধারণার পুরোনো বানান, তাই আপনার ইনস্টল করা সংস্করণ যে নির্দেশিকা নথিভুক্ত করে সেটিই ব্যবহার করুন। যেভাবেই হোক পরিবর্তনটা সার্ভারে ঘটে, এবং কোনো ক্লায়েন্ট প্রোফাইল তা করতে পারে না।

নিচের অংশটি সার্ভার দিকের সম্পূর্ণ পরিবর্তন, এবং একা এটি কোনো কার্যকর প্রমাণীকরণ কনফিগারেশন নয়। verify-client-cert none সার্টিফিকেটের দাবি সরায়, আর username-as-common-name অ্যাকাউন্টের নামকে সেই পরিচয়ে পরিণত করে যা পরবর্তী কলব্যাক ও প্রতি-ক্লায়েন্ট ফাইল দেখে। কোনো লাইনই পাসওয়ার্ড যাচাই করে না, তাই একটি যাচাইকারীকে এখনও থাকতে হবে।

verify-client-cert none
username-as-common-name

সেই যাচাইকারী একটি প্লাগইন বা auth-user-pass-verify দ্বারা চালিত একটি স্ক্রিপ্ট, এবং উপরের যেকোনো লাইন অর্থবহ হওয়ার আগেই এটিকে জায়গায় থাকতে হবে। ক্রম উল্টে দিলে আপনি এমন একটি জানালা পান যেখানে সার্ভার কোনো সার্টিফিকেট চায় না এবং কোনো অ্যাকাউন্টও যাচাই করে না।

সার্ভারকে এখনও কী যাচাই করে

ক্লায়েন্ট সার্টিফিকেট বাদ দিলে TLS বাদ পড়ে না। সার্ভার তার সার্টিফিকেট ও কী রাখে, আর ক্লায়েন্ট CA বিশ্বাস ও হোস্টনেম যাচাই রাখে যা তাকে কোনো প্রতারকের সঙ্গে কথা বলতে দেয় না। ক্লায়েন্টের আর সার্টিফিকেট নেই বলে remote-cert-tls server বা CA বান্ডল সরানো একটি সাধারণ ও গুরুতর ভুল পাঠ, এবং 2.6 রেফারেন্স স্পষ্ট যে দুটি দিক স্বাধীন। একটি ক্লায়েন্টের কাছে সার্ভার প্রমাণ করে; অন্যটি সার্ভারের কাছে ক্লায়েন্ট প্রমাণ করে।

একটি প্রোফাইল tls-auth বা tls-crypt ব্লকও বহন করতে পারে। এটি নিজস্ব বিতরণ ও ঘূর্ণন চক্রসহ একটি ভাগ করা নিয়ন্ত্রণ-চ্যানেল কী, তাই সার্টিফিকেট বা কী লাইন ছাড়া একটি ফাইল স্বয়ংক্রিয়ভাবে প্রকাশের জন্য নিরাপদ নয়। এটি পড়া পর্যন্ত এটিকে গোপনীয় হিসেবে গণ্য করুন।

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

যাচাইকারীকে কী করতে হবে

সার্টিফিকেটের দাবি সরানো হলে সবকিছু যাচাইকারীর উপর দাঁড়ায়: একটি প্লাগইন, বা auth-user-pass-verify দ্বারা চালিত একটি স্ক্রিপ্ট। এটিকে অবৈধ পরিচয়পত্র প্রত্যাখ্যান করতে হবে, নিষ্ক্রিয় বা অযোগ্য অ্যাকাউন্ট প্রত্যাখ্যান করতে হবে, এবং যখন তার ব্যাকএন্ডে পৌঁছাতে পারে না তখন বন্ধভাবে ব্যর্থ হতে হবে। username-as-common-name প্রায়ই পাশাপাশি সক্রিয় করা হয়, এবং এটি সেই পরিচয় বদলে দেয় যা পরবর্তী কলব্যাক ও প্রতি-ক্লায়েন্ট কনফিগারেশন ফাইল দেখে। এটি পাসওয়ার্ড যাচাই করে না, এবং অযোগ্য অ্যাকাউন্টকে যোগ্য করে না। এগুলো আলাদা কাজ, এবং এগুলো গুলিয়ে ফেলাই হলো যেভাবে একটি মাইগ্রেশন তার সুখী-পথের পরীক্ষায় পাস করে আর তার প্রথম বাস্তব ঘটনায় ব্যর্থ হয়।

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

নীতি, প্রোফাইল ও ম্যাপিং একসঙ্গে বদলান

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

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

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