আসলে কোন OpenVPN ইনস্ট্যান্স আপনার PiVPN প্রোফাইল ব্যবহার করছে?

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

হেল্পার আর ডেমন আলাদা বস্তু

বিভ্রান্তিটা সহজেই বোঝা যায়: একটি ডিরেক্টরিতে থাকে হেল্পারের তৈরি ফাইল, ডেমনের পড়া ফাইল, আর মাঝে মাঝে দুটোরই একটি পুরোনো কপি। হেল্পার হলো একটি প্রভিশনিং স্ক্রিপ্ট। এটি প্যাকেজ ইনস্টল করে, ইউনিট ফাইল লেখে এবং একটি ক্লায়েন্ট প্রোফাইল প্রিন্ট করে, তারপর তার কাজ শেষ। যা থেকে যায় তা হলো সার্ভিস-ম্যানেজারের একটি এন্ট্রি আর একটি কমান্ড লাইন।

systemd হোস্টে ডিরেক্টরি তালিকা নয়, সক্রিয় ইউনিট থেকে শুরু করুন। নামটি প্যাকেজিংয়ের উপর নির্ভর করে: Debian ও Raspberry Pi OS ইমেজ সাধারণত একটি টেমপ্লেট ইনস্ট্যান্স দেয়, যেমন openvpn-server@server, আর পুরোনো ইনস্টল ব্যবহার করে openvpn@server। ফাইলের নাম থেকে অনুমান না করে ম্যানেজারকে জিজ্ঞাসা করুন কোনটি চলছে।

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

পড়ুন ExecStart= ওই আউটপুটে। এটি এক্সিকিউটেবল এবং ম্যানেজার যে অপশনগুলো সত্যিই চালু করে তা বলে, যেকোনো --config পাথসহ; পাশে থাকা কোনো কনফিগারেশন ফাইল, যার দিকে কোনো কমান্ড ইশারা করে না, চলমান টানেলের অংশ নয়।

ডেমন যে কনফিগারেশন চেইন সমাধান করেছে তা অনুসরণ করুন

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

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

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

হোম ডিরেক্টরির একটি .ovpn ফাইল ক্লায়েন্ট আর্টিফ্যাক্ট। সার্ভার ডেমন এটি কখনো পড়ে না, তাই সার্ভার-সাইড হ্যান্ডশেক ব্যর্থতা ঠিক করতে ওই ফাইল সম্পাদনা করলে কিছুই হয় না।

ইনক্লুডগুলো আরেকটি ফাঁদ। একটি config লাইন একটি দ্বিতীয় ফাইল টেনে আনে যার অপশনগুলো ওই বিন্দুতে প্রক্রিয়া হয়, তাই পরে আসা একক-মানের নির্দেশনা মূল ফাইল যা বলছে বলে মনে হচ্ছে তা ছাপিয়ে যেতে পারে। দৃশ্যমান ফাইল সঠিক মনে হলে আর ডেমন তবু আলাদা আচরণ করলে, কিছু বদলানোর আগে অন্তর্ভুক্ত ফাইলটি পড়ুন।

লগকে প্রসেসের সঙ্গে মেলান, আপনার মনে থাকা ত্রুটির সঙ্গে নয়

দুটি লগিং গন্তব্য সাধারণ, আর তাদের একটিই জার্নাল। log-append সেট থাকলে ডেমন ওই ফাইলে লেখে আর জার্নাল স্টার্টআপ লাইনের বাইরে খুব কম রাখে। এটি না থাকলে journalctl ইভেন্টের উৎস।

journalctl -u openvpn-server@server -n 80 --no-pager

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

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

শেষের সাধারণটি নয়, প্রথম নির্দিষ্ট ব্যর্থতাটি লিখে রাখুন। বাইন্ড ত্রুটি, উত্তরহীন বহিঃস্থ বিনিময়, সার্টিফিকেট প্রত্যাখ্যান আর অ্যাকাউন্ট প্রত্যাখ্যান প্রত্যেকটি আপনাকে ভিন্ন স্তরে পাঠায়, আর শেষের টাইমআউট প্রায়ই উপরের কাজের ইভেন্টটি ঢেকে দেয়।

টানেল পুনর্নির্মাণ কোনো ডায়াগনস্টিক ধাপ নয়

লোভনীয় শর্টকাট হলো আরেকটি সরল টানেল দাঁড় করানো: স্ট্যাটিক কি, কোনো সার্টিফিকেট নেই, অতিরিক্ত প্রমাণীকরণ নেই। এটি প্রায়ই সংযোগ করবে, আর এটি কেবল প্রমাণ করে দুটি হোস্ট তাদের মধ্যে UDP বা TCP পার করতে পারে। সার্টিফিকেট-প্রমাণিত ডিপ্লয়মেন্ট কেন ব্যর্থ হয় সে সম্পর্কে এটি কিছুই বলে না, আর আপনি যে নিরাপত্তা মডেল রাখতে বলা হয়েছিল তা নিঃশব্দে বদলে দেয়।

একই কথা প্রযোজ্য tls-auth বা tls-crypt নিষ্ক্রিয় করা, verify-x509-name শিথিল করা, বা সবুজ স্ট্যাটাস পেতে দ্বিতীয় ফ্যাক্টর বাদ দেওয়ার ক্ষেত্রে। যে টানেল যাচাই সরানোর কারণে সংযোগ করে তা ভিন্ন একটি সিস্টেম, মেরামত করা নয়।

লগ যে স্তরটির নাম দিয়েছে সেখানে একটি সীমিত পরিবর্তন করুন, একই ইউনিট রিস্টার্ট করুন, আর একক সংযোগ প্রচেষ্টাটি পুনরাবৃত্তি করুন। এটি তুলনাটি সৎ রাখে, আর আপনি ফিরিয়ে নিতে পারেন এমন একটি পরিবর্তন রেখে যায়।

পরের মানুষের হাতে কী দেবেন

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

শেয়ার করার আগে সংবেদনশীল তথ্য মুছুন। প্রাইভেট কি, auth-user-pass ফাইল, স্ট্যাটিক কি উপাদান আর সম্পূর্ণ ক্লায়েন্ট বান্ডল টিকিটে থাকা উচিত নয়; অপশনের নাম আর চেইনের আকৃতি সাধারণত দ্বিতীয় জোড়া চোখের জন্য যথেষ্ট।

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