SECLEVEL=0 উপসর্গ সারায়, সার্টিফিকেট নয়

OpenVPN সংযোগ ব্যর্থ হয়, কেউ এক লাইনের সমাধান খুঁজে পায় যা SECLEVEL=0 যোগ করে, আর টানেল উঠে আসে। যা বদলেছে তা সার্টিফিকেট নয়, সাইফার স্যুটও নয়; লাইব্রেরি-ব্যাপী একটি গ্রহণযোগ্যতার সীমা সরে গেছে, আর প্রক্রিয়াটি এর পরে যা কিছু করে তা সেই নতুন সীমা উত্তরাধিকারে পায়। একই লাইন পুরো এস্টেটের প্রতিটি প্রোফাইলে কপি হওয়ার আগে এটি বোঝা দরকার।

কোন লাইব্রেরি ও কোন নীতি কার্যকর তা নির্ধারণ করুন

SECLEVEL হলো OpenSSL-এর একটি ধারণা, তাই প্রথম প্রশ্ন এই যে আপনার বিল্ড আদৌ OpenSSL ব্যবহার করে কি না। OpenVPN একাধিক ক্রিপ্টোগ্রাফি লাইব্রেরির সঙ্গে লিংক হতে পারে, আর তাদের একটির জন্য প্রযোজ্য সেটিং অন্যগুলোর কাছে অর্থহীন। বাইনারিকে জিজ্ঞেস করুন এটি কী দিয়ে তৈরি, তারপর লাইব্রেরিকে জিজ্ঞেস করুন এটি কোন সংস্করণ ও কনফিগারেশন লোড করেছে:

openvpn --version | head -3
openssl version -a

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

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

প্রত্যাখ্যাত হতে পারে এমন তিনটি জিনিস আলাদা করুন

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

এদের তিনটির কোনোটিই ডেটা-চ্যানেলের সাইফার নয়। OpenVPN তার টানেল এনক্রিপশন TLS হ্যান্ডশেক থেকে আলাদাভাবে দর-কষাকষি করে, তাই নিরাপত্তা স্তর বদলানোর পরে সফল হওয়া সংযোগ আপনার পেলোড কোন সাইফার রক্ষা করে সে সম্পর্কে কিছুই বলে না। আপনি যদি আসলে ডেটার গোপনীয়তা সম্পর্কে জিজ্ঞেস করেন, তবে আপনি সম্পূর্ণ ভুল নিয়ন্ত্রণে হাত দিচ্ছেন।

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

ইনপুট বদলান, সীমা নয়

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

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

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

যদি কমাতেই হয়, পরিধি সীমিত করুন ও নথিভুক্ত করুন

কখনো অনুমোদিত সামঞ্জস্য-ব্যতিক্রমই সঠিক উত্তর, বিশেষত এমন পুরোনো পিয়ারের জন্য যার অবসান পরিকল্পনা তারিখযুক্ত। এটি পুরো হোস্টের বদলে যে সেবার প্রয়োজন সেই সেবায় সীমিত করুন: সেবা-নির্দিষ্ট কনফিগারেশন ফাইল বা নিবেদিত OpenSSL কনফিগারেশন গ্লোবাল প্রোফাইলে এক্সপোর্টের চেয়ে ছোট প্রভাব-ব্যাসার্ধ রাখে।

ব্যতিক্রমের সঙ্গে চারটি বিষয় লিখুন: সঠিক সেটিং, যে মালিক এটি অনুমোদন করেছে, যেসব ক্লায়েন্ট ক্ষতিগ্রস্ত হয়, এবং যে শর্তে এটি সরানো হবে। অবসান-শর্তহীন ব্যতিক্রম হলো সাময়িক যুক্তি সংযুক্ত এক স্থায়ী দুর্বলতা।

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

পরে পরিচয় ও সুরক্ষা যাচাই করুন

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

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

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

নিরীক্ষা উত্তীর্ণ হস্তান্তর বলে কোন নীতি কোন ইনপুট প্রত্যাখ্যান করেছে, কী বদলানো হয়েছে, আর তার ফলে কী গ্রহণযোগ্য থাকে। “এটি SECLEVEL=0 দিয়ে কাজ করে” এক সংযোগ সম্পর্কে পর্যবেক্ষণ, মোতায়েনের নিরাপত্তা মূল্যায়ন নয়।