প্রতিদিন OpenVPN রিস্টার্ট করবেন? ঘড়ি নয়, ব্যর্থতাটি বেছে নিন

আপনি এমন একটি cron কাজ উত্তরাধিকারসূত্রে পান যা প্রতিদিন 04:10-এ OpenVPN রিস্টার্ট করে, এবং এটি এক বছর ধরে সবকিছু স্থিতিশীল রেখেছে। এটি নির্দিষ্ট সময়ে একটি সুস্থ টানেলও সংযোগচ্যুত করে এবং দুপুরের খাবারের সময় যে বিভ্রাট সত্যিই ঘটে তার জন্য কিছুই করে না। ক্যালেন্ডার অনুযায়ী রিস্টার্ট একটি রক্ষণাবেক্ষণ সিদ্ধান্ত। পুনরুদ্ধার হলো নির্দিষ্ট ট্রিগারযুক্ত একটি ভিন্ন নকশা।

তিন ধরনের ব্যর্থতার জন্য তিনজন ভিন্ন মালিক দরকার। আগে ব্যর্থতাটি বেছে নিন, তারপর ব্যবস্থাটি নিজেই আসবে।

তিনটি ব্যর্থতা, তিনজন মালিক

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

প্রত্যেকের নিজস্ব সংকেত ও নিজস্ব মালিক আছে। জীবিততা VPN প্রোটোকলের, প্রসেসের জীবনচক্র সার্ভিস ম্যানেজারের, আর অ্যাপ্লিকেশনের স্বাস্থ্য সংকীর্ণ ম্যান্ডেটযুক্ত মনিটরিংয়ের।

জীবিততার একটি অপশন কী করতে পারে আর কী করতে পারে না

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

এটি হারানো পিয়ারের জন্য সঠিক হাতিয়ার এবং মৃত প্রসেসের জন্য ভুল হাতিয়ার, কারণ প্রস্থান করা প্রসেস নিজের টাইমার চালাতে পারে না। এটি টানেলের পেছনের অ্যাপ্লিকেশন উত্তর দিচ্ছে কি না তাও বলে না, কারণ বিনিময়টি দুটি VPN প্রান্তের মধ্যে ঘটে। ভূমিকা, প্রত্যাশিত বাধা এবং পুনঃপ্রমাণীকরণের আচরণ যাচাই না করে অন্য স্থাপনা থেকে টাইমআউট জোড়া কপি করাই একটি স্থিতিশীল টানেলকে কম্পিত করে তোলার উপায়।

সার্ভিস ম্যানেজার কীসের মালিক

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

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

কখন নির্ধারিত রিস্টার্ট ন্যায্য

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

যদি রিস্টার্টটি কোনো পরিচিত লিক বা আটকে যাওয়া অবস্থা এড়াতে বিদ্যমান থাকে, তবে ইউনিটের বিবরণে তা লিখুন, নইলে পরের ব্যক্তি এটি চিরকাল রেখে দেবে।

গুরুত্বপূর্ণ ক্ষেত্রগুলো পরীক্ষা করুন: প্রসেস চালু থাকলেও পিয়ার উধাও হয়, প্রসেস বেরিয়ে যায়, পুনঃপ্রচেষ্টায় নতুন শংসাপত্র লাগে, এবং অ্যাপ্লিকেশন নষ্ট থাকলেও টানেল ফিরে আসে। দেখুন কোন উপাদান সাড়া দেয় আর পেছনে কী অবস্থা রেখে যায়।

সঠিক প্রশ্ন কত ঘন ঘন রিস্টার্ট করবেন তা নয়, বরং ব্যর্থতাটি আগে কী লক্ষ্য করা উচিত।