OpenVPN-এ persist-tun ও persist-key আসলে কী টিকে রাখে
দুটি অপশনই একটি সক্রিয় প্রক্রিয়ার ভেতরে নরম রিসেট কভার করে। এরা থামানোর পরে ইন্টারফেস রাখে না, এবং এরা ট্রাফিক ব্লক করার নীতি নয়।
পরিষেবা থামালে persist-tun সেট থাকলেও ইন্টারফেস সরে যায়। এটি অপশনটি ডকুমেন্টেশন অনুযায়ী কাজ করছে, ব্যর্থ হচ্ছে না। অপশনটি চলমান প্রক্রিয়ার ভেতরে একটি রিস্টার্ট পথ বর্ণনা করে, এবং systemctl stop সেই পথ নয়।
দুটি নাম একসাথে পড়ুন, নকশা স্পষ্ট হয়ে যায়। একটি ডেসক্রিপ্টর রাখে, অন্যটি কী উপাদান রাখে, এবং দুটিই বিদ্যমান কারণ বিশেষাধিকার ছাড়ার পরে যা ঘটে।
দুটি সম্পদ এবং যে রিসেটের তারা অন্তর্গত
OpenVPN দুইটি সাধারণ পরিস্থিতিতে নিজের রিস্টার্ট সংকেত দেয়। একটি স্পষ্ট SIGUSR1 তা করে, এবং মৃত পিয়ার দ্বারা ট্রিগার হওয়া একটি ping-restart একই কাজ করে। দুটিই প্রক্রিয়াকে জীবিত রাখে এবং সংযোগ সেটআপ আবার চালায়, এখানেই অপশনগুলো নিজেদের জায়গা পায়।
| Event | TUN/TAP device | Key and auth files | Addresses and routes | up/down hooks |
|---|---|---|---|---|
Soft reset, from SIGUSR1 or from a ping-restart the daemon sends itself | survives only with persist-tun | survive only with persist-key | survive with the device, otherwise rebuilt | run again only when restart hooks are enabled |
Configuration reload, SIGHUP | recreated | re-read from disk | rebuilt once the device returns | run again |
| Service stop | lost | re-read at the next start | removed | run at the next start |
শুধু নরম-রিসেট সারিই এই দুটি অপশন বদলায়, এবং যে কাজ তারা এড়িয়ে যায় সেটাই ব্যস্ত লিঙ্কে ব্যয়বহুল অংশ। ডিভাইস আবার খুললে তার সাথে যুক্ত ঠিকানা ও রুট ভেঙে যায়, এবং সেগুলো পুনর্গঠনে রিসেট শুরুর সময় চলমান প্যাকেট হারাতে পারে। থামানো একই বস্তুগুলো সংরক্ষণের কোনো অপশন ছাড়াই ধ্বংস করে।
অপশনগুলো আদৌ কেন আছে
কঠোর করা OpenVPN সার্ভার সাধারণত রুট হিসেবে শুরু হয়, নিজের কী ও ডিভাইস খোলে, তারপর অসুবিধাভোগী ব্যবহারকারীতে নেমে আসে। সেই অবতরণের পরে কিছু অপারেশন কেবল হারিয়ে যায়। মোড 0600 কী ফাইল পড়া, নেটওয়ার্ক ইন্টারফেস তৈরি করা বা রুট বদলানো সবই প্রত্যাখ্যাত হতে পারে।
persist অপশন ছাড়া, ping-restart ট্রিগার করার মতো যথেষ্ট সময় চুপ থাকা পিয়ার ঠিক সেই অপারেশনগুলো চাপিয়ে দিত। কনফিগারেশনে কিছু না বদলালেও পুনঃসংযোগ ব্যর্থ হতো। প্রক্রিয়াটি কারণ ছাড়াই মরে যাওয়ার মতো দেখাত, এবং লগ নেটওয়ার্ক ত্রুটির বদলে অনুমতি ত্রুটি দেখাত।
এগুলো থাকলে, নরম রিসেট বিশেষাধিকারপ্রাপ্ত পর্যায় ইতিমধ্যে যা পেয়েছে তা পুনরায় ব্যবহার করে। কোনো জাদু নেই এবং প্রক্রিয়াটি কিছুই টিকিয়ে রাখে না। সম্পদ অর্জন কেবল বিলম্বিত হয়।
শেষটি নয়, প্রথম ত্রুটিটি পড়ুন
রিসেট ব্যর্থ হলে, শেষটির বদলে প্রথম ত্রুটিটি পড়ুন। একটি সুরক্ষিত কী, একটি auth ফাইল, একটি ইন্টারফেস ioctl এবং একটি বাহ্যিক হুক চারটি ভিন্ন সম্পদ। একটি ধরে রাখা অন্যগুলোতে প্রবেশ সম্পর্কে কিছুই বলে না। ফায়ারওয়াল টুল ডাকা একটি হুকের এখনও সেই টুলের দাবি করা বিশেষাধিকার লাগে।
হুকগুলোর নিজস্ব সুইচ আছে। OpenVPN ম্যানুয়াল persist অপশনগুলোকে up-restart এর সাথে জোড়া দেয়, যা ঠিক করে রিস্টার্টের পরে up ও down স্ক্রিপ্ট আবার চলে কি না। তাই টিকে থাকা একটি ইন্টারফেস আপনার রিজলভার ইন্টিগ্রেশন রিফ্রেশ হয়েছে কি না তা কিছুই বলে না।
# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'
# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0এই দুটি কমান্ড দুইটি ব্যর্থতার মোডকে সেকেন্ডে আলাদা করে। উপস্থিত কিন্তু রুট হারানো ইন্টারফেস একটি হুক বা রুট সমস্যা। উধাও হওয়া ইন্টারফেস মানে প্রক্রিয়াটি সত্যিই শেষ হয়েছে।
টিকে থাকা ইন্টারফেস কোনো কিল সুইচ নয়
যদি দাবি হয় ট্রাফিক কখনও টানেলের বাইরে যাবে না, তবে সংরক্ষিত ডিভাইস তা দেয় না। অন্য ঠিকানা পরিবারের রুট, দ্বিতীয় ডিফল্ট রুট, এবং প্রক্রিয়া সম্পূর্ণ বন্ধ হওয়ার ক্ষেত্র সবই অপশনের পরিধির বাইরে থাকে।
দুটি দাবি আলাদাভাবে দেখুন। পুনঃসংযোগের মধ্যে টানেল বস্তু রাখা ডেমনটির জন্য সুবিধা। টানেল বন্ধ থাকলে বের হওয়া ব্লক করা নিজস্ব নিয়ম ও নিজস্ব পরীক্ষাসহ একটি ফায়ারওয়াল নীতি। এগুলো মিশিয়ে দিলে এমন কনফিগ হয় যা প্রতিরক্ষামূলক দেখায় আর সেরা-চেষ্টা পুনঃসংযোগের মতো আচরণ করে।
নির্ণয়ের আগে ঘটনার নাম দিন। একটি নরম রিসেট, একটি ব্যর্থ সংযোগ প্রচেষ্টা এবং একটি পরিষেবা থামানো তিনটি আচরণসহ তিনটি ঘটনা, এবং শুধু প্রথমটিই এই অপশনগুলো বর্ণনা করে।