OpenVPN প্রোফাইলের বহনযোগ্যতা: বহনযোগ্য কী বনাম প্ল্যাটফর্মের অপশন

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

পরিচয়ের সঙ্গে যা ভ্রমণ করে আর প্ল্যাটফর্মের যা তা আলাদা করুন। তখন ব্যর্থতা সাধারণত নিজেই নিজের নাম বলে দেয়।

এক ফাইল, দুই চুক্তি

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

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

বহনযোগ্য উপাদান বনাম প্ল্যাটফর্মের নির্দেশ

পরিচয় ও পরিবহন অংশটিই সংরক্ষণ করার জিনিস। ca, cert, key ও remote বলে কে কোথায় সংযোগ করছে, এবং মানসম্মত যেকোনো ক্লায়েন্টের কাছে এদের অর্থ একই।

আচরণ নির্দেশই তুলনা করার অংশ। উদাহরণস্বরূপ block-outside-dns Windows-এর DNS আচরণ বদলাতে তৈরি। Unix ক্লায়েন্ট একে আদৌ নাও চিনতে পারে।

পাঠানো ক্লায়েন্টের নয়, গ্রহণকারী ক্লায়েন্টের অপশন তালিকা পড়ুন। OpenVPN 2.6 রেফারেন্স ম্যানুয়াল ইঞ্জিনের অপশন নথিভুক্ত করে, আর GUI-র ইমপোর্ট ডায়ালগ সেই তালিকা নয়।

সার্টিফিকেটের আগে পার্সার ত্রুটি পড়ুন

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

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

মূল ফাইলটি অভিযোজিত ফাইলের পাশে রাখুন। পরে অভিযোজিত ফাইল ব্যর্থ হলে মূলটিই সেই নিয়ন্ত্রণ যা বলে দেয় পরিবর্তন নাকি পরিবেশ সরে গেছে।

বিশেষাধিকার দ্বিতীয় সীমা

বিশেষাধিকার হলো অন্য সীমা: টানেল ডিভাইস তৈরি, রুট ইনস্টল এবং প্রাইভেট কী পড়া — সবই স্থানীয় অনুমতির ওপর নির্ভর করে। কেবল root-এর পাঠযোগ্য কী ফাইল স্বাভাবিক স্থাপনা, প্রোফাইলের ত্রুটি নয়। সমাধান মালিকানা বা সক্ষমতায়, ফাইলে নয়।

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

সচেতনভাবে অভিযোজন করুন

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

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