কেন একটি VPN ইউনিট নেটওয়ার্কের আগে শুরু হয় এবং পরে মারা যায়

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

লক্ষ্যটি একটি মিলনস্থল, কোনো পরিচালক নয়

network-online.target জানে না নেটওয়ার্ক কী। এটি একটি সমন্বয় বিন্দু যা সেই পরিষেবাটি সংগ্রহ করে যা লিংক ব্যবহারযোগ্য হওয়ার আগে স্টার্টআপ বিলম্বিত করার কথা, এবং এটি সংজ্ঞাটি মেশিনের মালিক যে নেটওয়ার্ক ম্যানেজার তার কাছে অর্পণ করে। বেশিরভাগ ডেস্কটপ ও সার্ভারে এর অর্থ NetworkManager বা systemd-networkd যে অপেক্ষা-পরিষেবা দেয় সেটি। কোনোটিই চালু না করলে লক্ষ্যের অপেক্ষা করার কিছু থাকে না, তাই যেকোনো কিছু এটিকে টেনে আনার মুহূর্তেই এটি সম্পন্ন হয়, যা DHCP উত্তর দেওয়ার অনেক আগেই হতে পারে। আপনার ইউনিটের ক্রম-লাইনটি সৎ ছিল এবং তবুও অকেজো।

তাই প্রথম প্রশ্নটি আপনার ইউনিট কী ঘোষণা করে তা নয়। প্রশ্নটি হলো, এই মেশিনে সত্যিই কি কিছু অপেক্ষাটি করছে।

ইউনিট ফাইলের বদলে শেষ বুটটি পড়ুন

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

নির্ভরতার দৃশ্যটি এটিকে সমর্থন করে। টানেল ইউনিটের একটি সংকটপূর্ণ শৃঙ্খলে যদি অপেক্ষা-পরিষেবা না থাকে, তবে সেই পথে কিছুই স্টার্টআপ বিলম্বিত করেনি, এবং লক্ষ্যটি আপনার ধরে নেওয়া কাজটি করেনি। দুটি দৃশ্য, একটি সিদ্ধান্ত।

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

অপেক্ষা যোগ করুন, তারপর পুনরায় চেষ্টা

প্যাকেজকৃত ইউনিট সম্পাদনার বদলে ড্রপ-ইন ব্যবহার করুন, যাতে প্যাকেজ আপডেট পরিবর্তনটি নীরবে ফেলে না দেয়। দুটি নির্দেশনা গুরুত্বপূর্ণ: ইউনিটটিকে লক্ষ্যের পরে ক্রমবদ্ধ করতে হবে, এবং লক্ষ্যটিকে একই লেনদেনে টেনে আনতে হবে। কেবল ক্রম লক্ষ্যকে ডাকে না; তা করার কাজটি ইচ্ছা করে।

প্যাকেজকৃত OpenVPN ক্লায়েন্ট ইউনিট ইতিমধ্যে দুটোই বহন করে। হাতে লেখা ইউনিট সাধারণত একটি বা কোনোটি বহন করে, যা কিছু যোগ করার আগে যাচাই করা উচিত।

[Service]
Restart=on-failure
RestartSec=15

কেন নির্দিষ্ট ঘুম একটি ফাঁদ

ExecStartPre-এ ঘুম ক্রম-সংশোধনের মতো মনে হয় এবং অতিরিক্ত ধাপযুক্ত বিলম্বের মতো আচরণ করে। এটি প্রতিটি বুট ধীর করে, এমনকি যেগুলো সুস্থ ছিল সেগুলোকেও, এবং আপনি যে সংখ্যাটি বেছেছেন তার চেয়ে লিংক বেশি সময় নিলে এটি তবুও হারে।

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

যখন ক্রম সঠিক কিন্তু নামগুলো তবুও ব্যর্থ হয়

টানেল রুটসহ একটি সক্রিয় ইউনিট মানে ক্রম তার কাজ করেছে এবং বাকি ত্রুটিটি এক স্তর উপরে। স্বাভাবিক রূপটি হলো টানেলের up স্ক্রিপ্ট যে রিজলভার সেটিং প্রয়োগ করে, লিংক বা রিজলভার তা ধরে রাখতে প্রস্তুত হওয়ার আগেই। ব্যর্থতার সময়ের রিজলভার অবস্থা টানেল ইউনিট রিস্টার্টের পরের অবস্থার সঙ্গে তুলনা করুন।

রিস্টার্ট যদি লুকআপ ঠিক করে, তবে আপনার আছে স্টার্টআপ ক্রমের ত্রুটি, ভুল DNS সার্ভার নয়, এবং এই দুটির আলাদা সমাধান দরকার। তারপর পুরো বিষয়টি সেবা রিস্টার্টের বদলে কোল্ড বুট দিয়ে প্রমাণ করুন, কারণ রিস্টার্ট এমন নেটওয়ার্কে চলে যা ইতিমধ্যে চালু এবং ঠিক যে ত্রুটিটি আপনি খুঁজছেন তা লুকাবে। লিংক উদ্দেশ্যমূলকভাবে ধীর রেখে এটি পুনরাবৃত্তি করুন, এবং যে ইউনিট কেবল দ্রুত নেটওয়ার্কে কাজ করে তাকে এখনও নষ্ট ধরুন।