ল্যাপটপ জাগার পরে OpenVPN কেন মরে যায়?
স্লিপ OpenVPN সেশনটি মেরে ফেলতে পারে অথচ tun0 রেখে যেতে পারে। টানেলটি পরীক্ষা করুন, তারপর ডিভাইস নয়, systemd স্লিপ হুক থেকে ইউনিটটি পুনরায় চালু করুন।
মেশিনটি সাসপেন্ড করুন, আবার রিজিউম করুন, তারপর কোনো কনফিগারেশন স্পর্শ করার আগে এই ক্রমে তিনটি জিনিস যাচাই করুন: tun0 এখনও আছে কি না, অভ্যন্তরীণ ঠিকানার রুট এখনও এটিই বেছে নেয় কি না, এবং সার্ভার এখনও এই পিয়ারকে তালিকাভুক্ত করে কি না। যে ডিভাইস স্লিপ থেকে টিকে থাকে অথচ রুট অন্য দিকে দেখায়, সেটি একটি অবশিষ্টাংশ, টানেল নয়। যখন রুট ঠিক থাকে আর ট্রাফিক তবুও মরে, ত্রুটি টানেলের উপরে থাকে এবং ক্লায়েন্ট পুনরায় চালু করলে তা বদলাবে না। হাতে করা পরীক্ষা এই তিনটির মধ্যে কোনটি আপনার ক্ষেত্রে তা দেখানোর পরেই পুনরায় চালু করা স্বয়ংক্রিয় করার অর্থ হয়।
ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30
স্বয়ংক্রিয় করার আগে রিজিউমটি পুনরুৎপাদন করুন
সাসপেন্ড করা ডিভাইসটি সরানোর চেয়ে বেশি বার এনক্রিপ্টেড সেশনটি শেষ করে। যে UDP প্রবাহ টানেলটিকে জীবিত রাখত তা থেমে যায়, সার্ভার পিয়ারটি ফেলে দিতে পারে, এবং ক্লায়েন্ট হয় তা লক্ষ্য করে আবার সংযোগ করে, নয়তো পেছনে কিছু না থাকা একটি ইন্টারফেস ধরে রাখে। একা ইন্টারফেস পরীক্ষা খুব কম প্রমাণ করে, কারণ পুরোনো ডিভাইস দেখতে হুবহু কাজ করা ডিভাইসের মতো যতক্ষণ না প্যাকেটকে এর মধ্য দিয়ে যেতে হয়। রুট লুকআপ চালান এবং টানেলের মধ্য দিয়ে একটি বাস্তব অনুরোধ করুন, তারপর রিজিউমের মুহূর্তের আশপাশের জার্নাল পড়ুন।
ক্লায়েন্ট নিজে থেকেই ফিরে এলে একটি হুক নির্ভরযোগ্যতার বদলে বাড়তি ঝামেলা যোগ করে। যদি এটি কখনোই সেরে না ওঠে, স্বয়ংক্রিয়করণই সৎ সমাধান।
systemd স্লিপ হুক আসলে কোথায় থাকে
অনেক পুরোনো গাইড /etc/pm/sleep.d দেখায়, যা pm-utils-এর মালিকানাধীন একটি ডিরেক্টরি এবং systemd-ভিত্তিক সাসপেন্ড কখনোই এটির পরামর্শ নেয় না। systemd হুক পড়ে /usr/lib/systemd/system-sleep/ এবং /etc/systemd/system-sleep/ থেকে, প্রথমে ফেজ ও পরে অপারেশন হস্তান্তর করে, তাই pre এবং post-ই একমাত্র মান যার উপর একটি হুক শাখা করে। প্যাকেজ করা ফাইল সম্পাদনার বদলে স্থানীয় কপিটি /etc-এর নিচে রাখুন, এবং মনে রাখুন স্ক্রিপ্টটি রূপান্তরের মাঝখানে root হিসেবে চলে, তাই এটি দ্রুত ফিরতে হবে।
#!/bin/sh
case "$1" in
post)
systemctl --no-block try-restart [email protected]
;;
esac
exit 0
try-restart একটি ইউনিটকে স্পর্শ করে কেবল তখনই যখন এটি ইতিমধ্যে সক্রিয়, তাই যে টানেল আপনি ইচ্ছাকৃতভাবে বন্ধ করেছেন তা রিজিউম জুড়ে বন্ধই থাকে। --no-block হুকটিকে ক্লায়েন্ট আলাপচারিতা করার সময় অপেক্ষা করা থেকে বিরত রাখে, যা তখন গুরুত্বপূর্ণ যখন নেটওয়ার্ক এখনও ওঠেনি। দুটি ফ্ল্যাগ একসাথে বোঝায় এমন একটি হুক যা পুরো রিজিউম ক্রম ধরে রাখার বদলে চুপচাপ ব্যর্থ হয়। ইউনিট ইতিমধ্যে বন্ধ থাকলে আদৌ কিছু ঘটে না, যা ঠিক সেই ফলাফল যা আপনি সেখানে চান।
সার্ভিসটি উদ্ধার করুন, tun0-কে একা ছেড়ে দিন
tun0 হাতে নামালে ডেমন এমন একটি ইন্টারফেস তদারকি করতে থাকে যা আর তার মালিকানা নয়, এবং পরবর্তী অবস্থা পরিবর্তনে বিভ্রান্তিকর ত্রুটি তৈরি হয়। ইন্টারফেসের বদলে সার্ভিস বা তার সংযোগ প্রোফাইলকে লক্ষ্য করুন; আগে সঠিক ইউনিটের নাম যাচাই করুন, কারণ ডিস্ট্রিবিউশন প্যাকেজ, OpenVPN 3 এবং NetworkManager সবাই আলাদা নাম বেছে নেয়। NetworkManager প্রোফাইল ফিরে আসে যখন সেই সংযোগটি চক্রাকারে চালানো হয়, তাই systemd ইউনিট সেখানে লক্ষ্য নয়। প্রক্রিয়াটি যাই হোক, এটি সেই একই কাজ হওয়া উচিত যা আপনি হাতে যাচাই করেছেন।
পুনরায় চালু করা সেই রুটগুলো পুনঃস্থাপন করে যা ক্লায়েন্ট সংযোগের সময় ঠেলে দিয়েছিল। বেশিরভাগ রিজিউম তা-ই চায়। যে মেশিনে আপনি নিজের পথ যোগ করেছেন সেটি চায় না, তাই পুনরুদ্ধার সেগুলো ফিরিয়ে দিয়েছে ধরে নেওয়ার বদলে সেগুলো আবার যাচাই করুন, এবং পরবর্তী রিজিউম যেখানে খুঁজে পাবে সেখানে লিখে রাখুন।
যে সময় আপনি নিয়ন্ত্রণ করতে পারেন না তা সামলান
ওয়্যারলেস অ্যাসোসিয়েশন এবং DHCP প্রায়ই হুক চলার পরে শেষ হয়, তাই সার্ভারের পথ এখনও না থাকা অবস্থায় পুনরায় চালু করা ব্যর্থ হতে পারে। সেই ঠিকানার জন্য অল্পক্ষণ অপেক্ষা করুন, একবার আবার চেষ্টা করুন এবং ফলাফল লগ করুন।
নাম রিজলিউশন আলাদা একটি দৌড়, কারণ ডেস্কটপ নেটওয়ার্ক স্ট্যাক টানেল ওঠার পরেও DNS পুনরুদ্ধার করতে পারে। কাজ করা রুট থেকে অনুমান করার বদলে resolvectl query internal.example দিয়ে লুকআপ আলাদাভাবে পরীক্ষা করুন। যে টানেল সঠিকভাবে রুট করে কিন্তু কিছুই রিজলভ করে না, সেটি DNS সমস্যা, হুকের সমস্যা নয়।
জার্নালে ফেজ, ইউনিটের নাম ও ফলাফল লিখে হুকের সিদ্ধান্ত দৃশ্যমান রাখুন। মেশিনের নোটে লিখে রাখুন আপনি কোন রিজিউম পরীক্ষা চালিয়েছেন, যাতে কাজ করা পুনরুদ্ধারকে ভাগ্যবান পুনরুদ্ধার থেকে আলাদা করা যায়। পরিষেবা ফিরিয়ে আনে এমন সবচেয়ে কম বিঘ্নকারী পদক্ষেপ বেছে নিন, এবং যে ক্লায়েন্ট নিজে থেকেই সেরে ওঠে তাকে তা করতে দিন। সম্পূর্ণ পুনরায় চালু চলমান সেশন ফেলে দেয়, যা দিনে কয়েকবার রিজিউম করা ল্যাপটপে সত্যিকারের খরচ।