OpenVPN প্রোফাইল থেকে key-method মুছে ফেললে কিছুই বদলায় না

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

একটি প্রোফাইলে কী আছে আর প্রোটোকল আসলে কী করে—এই ফাঁকটাই এখানে মূল বিষয়, এবং এটি একই সময়ে মানুষ যে আরও কয়েকটি সম্পাদনা করে তা ব্যাখ্যা করে। এটি এটাও ব্যাখ্যা করে কেন ওই সম্পাদনাগুলো সাধারণত একত্রে আসে।

উপসর্গটি হ্যান্ডশেক ব্যর্থতা নয়, একটি পার্স ত্রুটি

কোনো প্যাকেট পাঠানোর আগেই অপশনগুলো পড়া হয়। অজানা নির্দেশিকাযুক্ত প্রোফাইল ওই পর্যায়ে ব্যর্থ হয়, তাই প্রসেসটি কখনো নেটওয়ার্কে পৌঁছায় না এবং কখনো হ্যান্ডশেক ত্রুটি তৈরি করে না। শব্দবিন্যাস সাধারণত অপশন ও ফাইলটি চিহ্নিত করে, যা এটিকে কারণনির্ধারণের সহজতম ব্যর্থতাগুলোর একটি করে তোলে। এতে কোনো প্যাকেট, রুট বা ফায়ারওয়াল জড়িত নয়।

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

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

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

নির্দেশিকা ও ওয়্যার ফরম্যাট দুই ভিন্ন জিনিস

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

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

একটি উপকারী যাচাই হলো সংস্করণ ও পার্স করা কনফিগারেশন, ফাইলে শব্দটির উপস্থিতি নয়:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

কী সরাতে হবে, এবং কোন ফাইল থেকে

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

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

তারপর অভীষ্ট ইনস্ট্যান্সটি চালু করুন এবং এর স্টার্টআপ আউটপুট পড়ুন। লিসেনার উপস্থিত থাকা অবস্থায় পরিষ্কার স্টার্টআপই এই পর্যায় শেষ হওয়ার নিশ্চয়তা; এরপরের ক্লায়েন্ট পরীক্ষা ভিন্ন একটি প্রশ্নের উত্তর দেয়।

প্রত্যাখ্যাত প্রোফাইল ও প্রত্যাখ্যাত ক্লায়েন্ট দেখতে একই রকম

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

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

সামঞ্জস্যের যে প্রশ্নগুলোর উত্তর লাইনটি কখনো দেয়নি

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

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

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