OpenVPN up-এ সার্ভিস রিস্টার্ট: হুকগুলো tun0.device-এর চেয়ে ভালো

একটি নির্ভরশীল সার্ভিসকে tun0.device -এর সাথে যুক্ত করা টানেলে সাবস্ক্রাইব করার মতো দেখায়, কিন্তু তা নয়। একটি ডিভাইস ইউনিট দেখায় যে ইন্টারফেসটি বিদ্যমান, যা একটি ব্যর্থ সংযোগ এবং তার পরবর্তী পুনঃসংযোগ জুড়ে সত্য থাকতে পারে। তখন সার্ভিসটি ভুল মুহূর্তে কাজ করে, অথবা কখনও করে না, ইন্টারফেসটি মাঝে অদৃশ্য হয়েছিল কি না তার উপর নির্ভর করে। যে ইভেন্টটি আপনার আসলে দরকার তা বর্ণনা করে সেই হুক, যেটি OpenVPN ডাকে, সেটিই, systemd যেটি অনুমান করে তা নয়।

ট্রিগার বেছে নেওয়ার আগে সার্ভিসের কোন শর্তটি দরকার তা ঠিক করুন, কারণ তিনটি প্রার্থী পরিবর্তনযোগ্য নয়।

ডিভাইস ইউনিট আসলে কী ট্র্যাক করে

systemd একটি নেটওয়ার্ক ইন্টারফেস সম্পর্কে কার্নেলের দৃষ্টিভঙ্গি থেকে একটি ডিভাইস ইউনিট তৈরি করে, তাই ইন্টারফেসটি উপস্থিত হলে tun0.device সক্রিয় হয় এবং সরিয়ে ফেলা হলে নিষ্ক্রিয় হয়। persist-tun -এর সাথে, একটি নরম রিস্টার্ট ইন্টারফেসটিকে জায়গায় রাখে, তাই ইউনিটটি কখনও ফ্ল্যাপ করে না এবং এর সাথে বাঁধা কিছুই ট্রিগার হয় না। অধ্যবসায় ছাড়াও, ইউনিটটি রুট, DNS বা দূরবর্তী প্রান্ত উত্তর দেয় কি না সে সম্পর্কে কিছুই বলে না।

এটি 'VPN প্রস্তুত' -এর জন্য একটি দুর্বল প্রক্সি করে তোলে। যে লিসেনার শুধুমাত্র স্থানীয় ঠিকানা প্রয়োজন তা ইন্টারফেসের অস্তিত্বে সন্তুষ্ট হতে পারে, যেখানে দূরবর্তী নেটওয়ার্কে একটি অ্যাপ্লিকেশন ডাকে এমন সার্ভিসের রুট এবং পৌঁছানোযোগ্যতা প্রয়োজন, যা ডিভাইস ইউনিট প্রকাশ করতে পারে না।

up, route-up এবং up-restart ভিন্ন অর্থ বহন করে

TUN/TAP ডিভাইস খোলা এবং ইন্টারফেস কনফিগার হওয়ার পরে up চলে, যা নির্ধারিত ঠিকানা বাঁধে এমন লিসেনারের জন্য সঠিক মুহূর্ত। রুট ইনস্টল হওয়ার পরে, কনফিগার করা রুট বিলম্বের অধীন হয়ে route-up চলে, এবং রুট পর্যায় সম্পূর্ণ হওয়া প্রয়োজন এমন কাজের জন্য উপযুক্ত। কোনোটিই প্রমাণ করে না যে দূরবর্তী অ্যাপ্লিকেশন উত্তর দেয়। তাদের মধ্যে বাছাই করা সার্ভিসের কী প্রয়োজন সে সম্পর্কে প্রশ্ন, কোন হুকটি বেশি সম্পূর্ণ শোনায় সে সম্পর্কে নয়।

persist-tun -এর সাথে, রিস্টার্ট ডিভাইসটি পুনঃব্যবহার করে, তাই up-restart সেট না থাকলে up আবার চলে না। সেই অপশনটি নথিভুক্ত রিস্টার্ট জীবনচক্রের জন্য up স্ক্রিপ্ট সক্ষম করে, এবং এর পরিবেশ প্রথম শুরুর তুলনায় হ্রাসপ্রাপ্ত। যে স্ক্রিপ্ট পূর্ণ পরিবেশ ধরে নেয় তা প্রথম সংযোগে কাজ করে এবং পরেরটিতে ব্যর্থ হয়।

কাজটি না অপেক্ষা করে পাঠান

যে হুক systemctl restart সিঙ্ক্রোনাসভাবে ডাকে তা এমন ইউনিটের বিরুদ্ধে ডেডলক হতে পারে যার ক্রম টানেলের জন্য অপেক্ষা করে। systemctl --no-block try-restart vpn-dependent.service কাজটি সারিবদ্ধ করে এবং ফিরে আসে, যা হুককে যে সংযোগে সাড়া দিচ্ছিল তা ব্লক করা থেকে বিরত রাখে। try-restart শুধুমাত্র চলমান ইউনিটে কাজ করে, আর restart নিষ্ক্রিয় ইউনিটও শুরু করে; অভ্যাসে নয়, সচেতনভাবে বেছে নিন।

সারিবদ্ধ করা যাচাই নয়। কাজ গৃহীত হওয়ার সাথে সাথে হুক সফলতা ফেরত দেয়, তাই যাচাইটি লক্ষ্য ইউনিটের জার্নালে বা তার প্রকৃত লিসেনার অবস্থায় ঘটতে হবে।

রিস্টার্ট নীতি ইউনিটে থাকে, হুকে নয়

RemainAfterExit=yes সহ একটি oneshot ইউনিট তার কমান্ড শেষ হওয়ার পরে সক্রিয় থাকে, এবং দ্বিতীয় স্টার্ট অনুরোধ কিছুই করে না কারণ systemd এটিকে ইতিমধ্যে শুরু হয়েছে বলে মনে করে। এটি এমন একটি বৈশিষ্ট্য যার চারপাশে ডিজাইন করতে হয়, পুনরাবৃত্ত স্টার্ট কলে কাজ করার মতো ত্রুটি নয়। কাজটি যদি প্রতি সংযোগে চালাতে হয়, তবে ইউনিটের এমন আকৃতি দরকার যা তা অনুমোদন করে।

After= ইউনিটগুলিকে ক্রমানুসারে রাখে, এবং BindsTo= জীবনকাল বাঁধে, কিন্তু কোনোটিই 'VPN পুনঃসংযোগ করলেই এটি রিস্টার্ট করো' বোঝায় না। টানেলে বাঁধা ইউনিট টানেল থামলে থামে; টানেল ফিরে এলে এটি নিজেকে রিস্টার্ট করে না, যদি না কিছু এটিকে আবার শুরু করে।

একটি নয়, তিনটি পুনঃসংযোগ পরীক্ষা করুন

কোল্ড বুট, সম্পূর্ণ ক্লায়েন্ট রিস্টার্ট এবং নরম পুনঃসংযোগ প্রত্যেকে ভিন্ন পথ অনুশীলন করে। নরম পুনঃসংযোগই সেই একটি যা অনুপস্থিত up-restart, হ্রাসপ্রাপ্ত পরিবেশ বা কখনও নিষ্ক্রিয় না হওয়া ডিভাইস ইউনিট প্রকাশ করে। তিনটিই চালান এবং উভয় দিক নিশ্চিত করুন: টানেল উঠলে সার্ভিস কাজ করে, এবং Wi-Fi রোমিংয়ের মতো অসম্পর্কিত লিঙ্ক পরিবর্তনে রিস্টার্ট হয় না।

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