পুরোনো .ovpn প্রোফাইল Ubuntu 24.04-এ ব্যর্থ হয়: কোন লাইনগুলো মুছবেন

প্রোফাইলটি ডাউনলোড হয়ে আমদানি হয়, তারপর ফাইলের 12 নম্বর লাইনে Unrecognized option বার্তা দিয়ে থেমে যায়, যেখানে keysize নামটির উল্লেখ থাকে। অ্যাকাউন্টে কিছুই বদলায়নি, আর সার্ভার এখনো অন্য ক্লায়েন্ট গ্রহণ করে। বদলেছে ক্লায়েন্ট নিজেই: Ubuntu 24.04 OpenVPN 2.6 ইনস্টল করে, অথচ রপ্তানিটি 2.4-এর জন্য লেখা। মেরামত হলো কয়েকটি মুছে ফেলার সংক্ষিপ্ত ধারা, আর ক্রমটি গুরুত্বপূর্ণ, কারণ প্রতিটি পুরোনো অপশন পরেরটি পড়ার আগেই পার্সিং বন্ধ করে দেয়।

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

OpenVPN কোন ফাইলে ও কোন লাইনে পার্সিং থেমেছে তা বলে দেয়, তাই প্রতি চালানিতে আপনি একটির বেশি সমস্যা সারাতে পারবেন না। প্রোফাইলটি ডেস্কটপ অ্যাপলেটের বদলে টার্মিনাল থেকে চালান, কারণ অ্যাপলেট সাধারণত stderr গিলে ফেলে আর লাইন নম্বরই আপনার পাওয়া একমাত্র নির্ভরযোগ্য সংকেত: sudo openvpn --config /etc/openvpn/client/provider.ovpn। ওই লাইনটি ঠিক করুন, আবার চালান, এবং পরের ব্যর্থতা ভিন্ন একটি অপশনের নাম বলবে বলে আশা করুন।

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

তিন ধরনের ব্যর্থতা, তিন রকম মেরামত

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

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

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

2.6 যা সরিয়েছে সেই অপশনগুলো এই ক্রমে মুছুন

এই প্রতিটি লাইন নিজেই পার্সিং থামায়, তাই ক্লায়েন্ট সেগুলো একটির পর একটি জানায়। তালিকাটি ক্রমে নামুন এবং প্রতিবার মোছার পর আবার চালান।

প্রথমে keysize মুছুন, কারণ এর কোনো আধুনিক সমতুল্য নেই এবং এর উপস্থিতি সাধারণত এমন সাইফার বোঝায় যা বর্তমান ক্লায়েন্ট যেকোনোভাবে প্রত্যাখ্যান করে। তারপর ncp-disable মুছুন, যা সাইফার নেগোশিয়েশন নিয়ন্ত্রণ করত, 2.5-এ অপ্রচলিত হয়েছিল এবং 2.6-এ আর নেই। ns-cert-type server-এর জায়গায় remote-cert-tls server বসান, যা সমর্থিত যাচাইয়ের মাধ্যমে একই উদ্দেশ্য প্রকাশ করে। 2.6 পরিবর্তনের ইতিহাস বাকি সরানোগুলোকে তাদের বিকল্পের পাশে তালিকাভুক্ত করে, তাই পার্সার এখনো যা প্রত্যাখ্যান করে তার নথিভুক্ত উত্তর আছে।

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

BF-CBC কেবল সীমিত ফলব্যাক হিসেবে চালু রাখুন

কিছু প্রদানকারী এখনো BF-CBC-তে সংযোগ শেষ করে, আর OpenVPN 2.6 সাহায্য ছাড়া এতে নেগোশিয়েট করবে না, কারণ সাইফারটির ব্লক 64 বিট। সংকীর্ণ সমাধান হলো একটি ফলব্যাক তালিকা আর OpenSSL-এর লিগেসি প্রদানকারী, পুরো ক্লায়েন্টকে ডাউনগ্রেড করা নয়।

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

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

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

ক্লায়েন্ট আসলে যে প্রোফাইল লোড করে তা দিয়ে যাচাই করুন

আমদানি করা সংযোগ প্রায়ই সিস্টেম ডিরেক্টরিতে অনুলিপি হয়, তাই ডাউনলোড ফোল্ডারের ফাইল সম্পাদনা করে কিছুই নাও বদলাতে পারে। যে অনুলিপিটি চলে সেটি খুঁজুন: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn। তারপর টানেল চালু করুন এবং লগের যে লাইনটি আসলে নির্বাচিত ডেটা চ্যানেল সাইফার জানায় তা পড়ুন। ফলব্যাকে হ্যান্ডশেক সম্পন্ন হওয়া সংযোগ বলে দেয় সার্ভার কখনো আধুনিক কিছু প্রস্তাব করেনি।

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

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