নেটওয়ার্ক চালু হওয়ার আগে OpenVPN শুরু হওয়া ব্যর্থতা নয়

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

কিংবদন্তি: সেবা চালু মানেই কাজ করা টানেল

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

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

ইউনিটের অবস্থার বদলে ইনস্ট্যান্সের জন্য জার্নাল পড়ুন। কারণের লাইনটি লগে আছে, অবস্থার লেবেলে নয়।

কিংবদন্তি: পুনরায় চেষ্টার সেটিংস সব ব্যর্থতা ঢেকে দেয়

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

এর কোনোটিই বিকৃত প্রোফাইল, অপাঠ্য ব্যক্তিগত কী বা প্রত্যাখ্যাত অ্যাকাউন্টে প্রযোজ্য নয়। সেগুলোর সংশোধন দরকার, আর যে ক্লায়েন্ট তাদের বারবার চেষ্টা করে সে এগোয় না।

অননুমোদিত সার্টিফিকেট চিরকাল পুনরায় চেষ্টা করা যাচাই সরানোর কারণ নয়। এটি ত্রুটি পড়ার কারণ।

কিংবদন্তি: একটি লঞ্চারই যথেষ্ট, তাই আরেকটি যোগ করুন

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

কোন উপাদান টানেলের মালিক তা ঠিক করুন কিছু যোগ করার আগে। তারপর অন্য লঞ্চারটি নিষ্ক্রিয় করে আশা করার বদলে সরিয়ে ফেলুন।

মালিক এটাও নির্ধারণ করে পুনরায় চেষ্টা ও শংসাপত্র কোথা থেকে আসে, তাই এই সিদ্ধান্ত যেকোনো টিউনিংয়ের আগে আসে। মালিকানা প্রথমে আসার কারণ ঠিক এটাই।

আসলে কী ক্রম দরকার

ক্রম একটি কনফিগার করা ঠিকানার জন্য অপেক্ষা করতে পারে, আর এটুকুই তার নিশ্চয়তা। network-online.target অ্যাক্টিভেশন বিলম্বিত করে যতক্ষণ না ম্যানেজার নেটওয়ার্ককে চালু মনে করে, আর চালু হওয়ার সংজ্ঞা ম্যানেজারের উপর নির্ভর করে। VPN হোস্টনাম রিজলভ হয় কি না, লিসেনার উত্তর দেয় কি না, বা ক্যাপটিভ পোর্টাল ডিভাইসটিকে ঢুকতে দিয়েছে কি না—এসব কিছুই এটি বলে না।

নির্ভরতা যোগ করার আগে ইনস্টল করা ইউনিট ও যেকোনো drop-in পড়ুন। প্রতিটি নেটওয়ার্ক সেবার উপর বিস্তৃত After= বুট বিলম্বিত করে, অথচ আপনার আসলে যে সংযোগ দরকার তা প্রতিষ্ঠা করে না।

যে নির্ভরতা পরীক্ষা করতে পারেন তা ক্রমে সাজান, বাকি সব প্রস্তুতি-প্রোব দিয়ে যাচাই করুন। যে প্রোব টানেল খোলে তা অনুমান করা টাইমারের চেয়ে ভালো।

টানেল প্রথমবার উঠে আসার পরে কী হয়

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

ইন্টারঅ্যাকটিভ প্রমাণীকরণ অনুপস্থিত-মনোযোগ পুনরুদ্ধারকে সীমিত করে। ব্যাকগ্রাউন্ড ইউনিট ডেস্কটপ কীরিং খোলে না বা MFA অনুরোধের উত্তর দেয় না, তাই সেবার প্রসঙ্গের জন্য অনুমোদিত শংসাপত্র ব্যবস্থা অনুসরণ করুন।

টানেল বন্ধ থাকা অবস্থায় অ্যাপ্লিকেশন কী করতে পারবে তা আলাদাভাবে ঠিক করুন। পুনরায় চেষ্টা সংযোগ ফিরিয়ে আনে, আর ব্লকিং নীতি ঠিক করে এই ফাঁকে সরাসরি ট্রাফিক অনুমোদিত কি না।