কেন আপনার OpenVPN ক্লায়েন্ট একটি টাইমআউটের পরেই বন্ধ হয়ে থাকে

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

ইউনিট আসলে কী করেছে তা থেকে শুরু করুন, মনিটরিং যা দাবি করে তা থেকে নয়। systemctl status openvpn-client@office এবং journalctl -u openvpn-client@office -n 50 প্রস্থানের কারণ এবং ক্লায়েন্ট চলে যাওয়ার আগে লেখা শেষ লাইনটি দেখায়।

কেউ খেয়াল করার আগেই প্রক্রিয়াটি বন্ধ হয়েছিল

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

দুটি ping নির্দেশ একই প্রোফাইলে একসাথে থাকতে পারে না, তাই একটি বেছে নিন এবং সিদ্ধান্তটি লিখে রাখুন। সার্ভারটিও দেখুন, কারণ তার নিজের ping-exit ক্লায়েন্ট কী চেয়েছে তা নির্বিশেষে সেশন বন্ধ করে, আর কে সেই সিদ্ধান্ত নিয়েছে তা কেবল সার্ভার লগেই লেখা থাকে।

ping-exit আর ping-restart-এর মধ্যে বেছে নেওয়া

নিজে ঠিক হয়ে ওঠা উচিত এমন ল্যাপটপ বা দূরবর্তী সাইটের জন্য ping-restart বেছে নিন, আর মৃত টানেলকে প্রক্রিয়া থামাতেই হবে যাতে অন্য কিছু তাতে সাড়া দিতে পারে এমন ক্ষেত্রে ping-exit রেখে দিন। সংখ্যার চেয়ে সম্পর্কটাই বেশি গুরুত্বপূর্ণ: ping 10 আর ping-restart 60 একসাথে মানে পরীক্ষার আগে দশ সেকেন্ড নীরবতা আর রিস্টার্টের আগে ষাট সেকেন্ড, যা ক্ষতিপূর্ণ মোবাইল লিংকে আক্রমণাত্মক আর তারের লিংকে যুক্তিসঙ্গত। কারণটি লাইনটির পাশে লিখুন, নইলে পরের পাঠক ধরে নেবে ডিফল্ট মানগুলো ইচ্ছাকৃত ছিল।

তারপর নিশ্চিত করুন যে আসলে প্রক্রিয়াটিই বন্ধ হয়েছে। টানেল মৃত থাকা অবস্থায় সক্রিয় বলে জানানো ইউনিট আলাদা ত্রুটি, যা নিচে আলোচনা করা হয়েছে।

এমন তত্ত্বাবধান যা সত্যিই ইউনিট পুনরায় চালু করে

systemd হোস্টে সবচেয়ে ছোট টেকসই পরিবর্তন হলো একটি drop-in ফাইল: Restart=on-failure এবং RestartSec=10, যা /etc/systemd/system/[email protected]/restart.conf ফাইলে থাকে। drop-in পড়া হয় কেবল তখনই যখন systemd নিজের সংজ্ঞা পুনরায় লোড করে, তাই পরে systemctl daemon-reload চালান। মানটি পৌঁছেছে ধরে নেওয়ার বদলে systemctl show -p Restart -p ExecMainStatus openvpn-client@office দিয়ে যাচাই করুন। ফাইলের নামের ইনস্ট্যান্সটিই সেই প্রোফাইল হতে হবে যা ইউনিট আসলে লোড করে, তাই office-এর জন্য লেখা ফাইল openvpn-client@home-এর জন্য কিছুই করে না।

on-failure একটি ক্ষেত্র উপেক্ষা করে: শূন্য স্ট্যাটাসে পরিষ্কার প্রস্থান। কিছু টিয়ারডাউন পথ এভাবেই শেষ হয়, তাই ম্যান পেজের ভাষায় ভরসা না করে রেকর্ড করা স্ট্যাটাস পড়ুন। আপনার ক্লায়েন্ট যদি শূন্য নিয়ে হাল ছেড়ে দেয়, তবে আপনার Restart=always দরকার, আর এর খরচ হলো সত্যিই ভাঙা প্রোফাইল বারবার ফিরে আসে যতক্ষণ না শুরুর হারের সীমা সক্রিয় হয় ও জার্নাল ভরে যায়।

Restart=always ইচ্ছাকৃতভাবে থামানোর পরেও সক্রিয় হয়। রক্ষণাবেক্ষণের জন্য systemctl stop ব্যবহার করুন, আর কাজ করার সময় ইউনিটটি বন্ধ থাকতে হলে সেটি মাস্ক করুন।

টানেল বন্ধ থাকার সময় ফাঁস ধরুন

তত্ত্বাবধান টানেল ফিরিয়ে আনে, কিন্তু টানেল অনুপস্থিত থাকার সময় ট্রাফিক বেরিয়ে যাওয়া থামায় না। persist-tun পুনঃসংযোগের মধ্যেও ডিভাইস ও তার রুট ধরে রাখে, যা সুবিধাজনক এবং একটি জানালা খুলে দেয়। ডিভাইস টিকে থাকে, রুটগুলো এখনও তার দিকেই যায়, আর প্যাকেটগুলো অরক্ষিত ও অজ্ঞাতভাবে বেরিয়ে যায়। এটি একটি নীতি সিদ্ধান্ত, নিরপেক্ষ ডিফল্ট নয়।

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

ক্লায়েন্ট ইচ্ছাকৃতভাবে থামিয়ে এটি পরীক্ষা করুন। systemctl stop openvpn-client@office চালান, তারপর curl -m 5 https://example.com, যা বাস্তবিক লিংকের ওপর সফল হওয়ার বদলে ব্যর্থ হওয়া উচিত। সফল হলে বোঝায় ফায়ারওয়াল নিয়মটি নেই বা অতিরিক্ত অনুমোদনশীল।

আবার সংযোগ করুন, টানেল আবার ট্রাফিক বহন করছে নিশ্চিত করুন, তারপরেই মনিটরিংয়ে চেকটি যোগ করুন। cron থেকে ip addr দিয়ে tun ডিভাইস খোঁজা সবচেয়ে বেশি ব্যর্থ হওয়া তত্ত্বাবধান, কারণ persist-tun থাকলে ডিভাইস সেশনের চেয়ে বেশি বাঁচে আর কিছু বহন না হলেও প্রোব সুস্থতার খবর দেয়।