DD-WRT-এ OpenVPN 2.5 লিসেনার মৃত? এটি যে কনফিগ তৈরি করেছে তা পড়ুন

DD-WRT-এ মৃত লিসেনার সাধারণত বোঝায় ডেমন তার কনফিগ পার্স করার সময়ই বন্ধ হয়ে গেছে, ফায়ারওয়ালের কোনো নিয়ম পোর্টটি আটকায়নি। OpenVPN 2.5 পুরোনো কনফিগ যেসব ডিফল্টের ওপর নির্ভর করত, তার কয়েকটি কড়া করেছে, আর পুরোনো বিল্ডে কাজ করা একটি তৈরি কনফিগ সকেট খোলার আগেই প্রত্যাখ্যাত হতে পারে। কারণ রাউটারের নিজের লগে থাকে, আর ইনপুট থাকে তৈরি করা ফাইলে। এই ক্রমে দুটোই পড়া যেকোনো প্যাকেট ক্যাপচারের চেয়ে দ্রুত।

ডেমন ফায়ারওয়াল নয়

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

কিছু বদলানোর আগে দুটি পরীক্ষা দিয়ে এদের আলাদা করুন, কারণ মৃত ডেমনের ওপর ফায়ারওয়াল সম্পাদনা কেবল দ্বিতীয় একটি চলক যোগ করে।

DD-WRT যে কনফিগ তৈরি করেছে তা পড়ুন

DD-WRT আপনাকে ওয়েব ইন্টারফেসে টাইপ করা টেক্সট OpenVPN-কে দেয় না। এটি একটি তৈরি কনফিগ লেখে /tmp/openvpn/openvpn.conf-এ এবং সেই ফাইল ধরে ডেমন চালু করে, তাই GUI-র ফিল্ড আর Additional Config-এর যেকোনো টেক্সট OpenVPN সেগুলো দেখার আগেই মিলিয়ে যায়। আপনি যদি তৈরি ফাইলের বদলে ফর্মটি ডিবাগ করেন, তবে আপনি প্রকৃত ইনপুট নয়, একটি অভিপ্রায় পড়ছেন। রিবুট /tmp মুছে ফেলার আগে ফাইলটি স্থায়ী কোনো জায়গায় কপি করুন।

তৈরি ফাইলটি আপনার উদ্দেশ্যের সঙ্গে মিলিয়ে দেখুন, বিশেষত যেখানে GUI এমন একটি ডিরেক্টিভ লেখে যা আপনি কখনো বেছে নেননি। যে ড্রপডাউন একটি অপ্রচলিত অপশন নির্গত করে, তা ফর্মে অদৃশ্য আর ডেমনের জন্য মারাত্মক।

তৈরি ফাইলটি যদি খালি হয় বা না থাকে, তবে ডেমন চালু হওয়ার পর্যন্তও পৌঁছায়নি, আর সমস্যাটি OpenVPN-এর আগের স্তরে।

OpenVPN 2.5 কী গ্রহণ করা বন্ধ করেছে

OpenVPN 2.5 ncp-ciphers-কে data-ciphers দিয়ে প্রতিস্থাপন করেছে, আর ডিফল্ট ন্যূনতম TLS সংস্করণ 1.2-এ তুলেছে। এটি কম্প্রেশন হ্যান্ডলিংও বদলেছে, ফলে যে পিয়ার কম্প্রেশন প্রস্তাব করে তাকে প্রত্যাখ্যান করা হয়, যদি না কনফিগ তা স্পষ্টভাবে অনুমোদন করে, এবং ns-cert-type-এর মতো পুরোনো অপশন নাম remote-cert-tls-এর বদলে অপ্রচলিত করেছে। এর প্রতিটি পরিবর্তন আগে কাজ করা একটি কনফিগকে পার্স বা নেগোশিয়েশন ব্যর্থতায় পরিণত করে।

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

লগে শেষ নয়, প্রথম ত্রুটিটি পড়ুন। প্রথম খারাপ ডিরেক্টিভেই পার্সিং থামে, আর তার পরের সবকিছু শাটডাউনের শব্দ।

Broadcom-নির্দিষ্ট পূর্বশর্ত

Broadcom বিল্ডে ডেমন ব্যবহার করার আগে টানেল ডিভাইসটি থাকতে হবে। tun মডিউল লোড আছে কি না এবং /dev/net/tun আছে কি না দেখুন, কারণ ডিভাইস না থাকলে স্টার্টআপ ব্যর্থতা হয় যার সার্টিফিকেটের সঙ্গে কোনো সম্পর্ক নেই। একই কথা DD-WRT রুট ও DNS-এর জন্য যে সহায়ক স্ক্রিপ্ট তৈরি করে তার ক্ষেত্রেও প্রযোজ্য: সেগুলো না থাকলে বা এক্সিকিউটেবল না হলে ডেমন চালু হয়েও সেটআপ শেষ করতে ব্যর্থ হতে পারে।

আসল বার্তাটি দরকার হলে তৈরি কনফিগের ওপর বেশি ভার্বোসিটি দিয়ে ডেমনটি ফোরগ্রাউন্ডে চালান। ফোরগ্রাউন্ড রান সেই পার্স ত্রুটিটি ছাপে যা init স্ক্রিপ্ট গিলে ফেলেছিল।

তারপর স্বাভাবিক সার্ভিস ফিরিয়ে দিন, কারণ ফোরগ্রাউন্ড ডেমন আর init স্ক্রিপ্ট পোর্ট নিয়ে লড়বে।

ক্লায়েন্ট ডিবাগ করার আগে লিসেনারের অস্তিত্ব প্রমাণ করুন

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

লিসেনার থাকার পরেই ক্লায়েন্ট-দিকের ডিবাগিং অর্থবহ। তখন দেখুন ক্লায়েন্টের সাইফার ও TLS সেটিংস সার্ভারের data-ciphers তালিকা ও ন্যূনতম সংস্করণের সঙ্গে মেলে, আর পোর্টটি সত্যিই রাউটারে ফরওয়ার্ড করা হয়েছে।

তৈরি কনফিগ আর যে লগ লাইনটি সমাধান প্রমাণ করেছিল তা রেখে দিন। পরের ফার্মওয়্যার আপডেট ডিফল্ট আবার বদলাতে পারে, আর সেই রেকর্ডই পুনরাবৃত্তিকে পাঁচ মিনিটের পরীক্ষায় বদলে দেয়।