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

দুটিই নির্দিষ্ট সময়ের ঘুমের চেয়ে ভালো, কারণ ঘুমটি কোনো কিছুর জন্য অপেক্ষা করে না, আর কীসের জন্য অপেক্ষা করছিল তাও জানায় না।

local অপশনটি আসলে যা দাবি করে

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

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

ঠিকানার জন্য অপেক্ষা বনাম বাইন্ড পুনরায় চেষ্টা

অপেক্ষা মানে হলো একটি ExecStartPre যা ঠিকানা না আসা পর্যন্ত জরিপ করে, সীমিত সংখ্যক চেষ্টা এবং সময় শেষ হলে অশূন্য প্রস্থানসহ। পুনরায় চেষ্টা মানে মূল প্রক্রিয়াটিকে ব্যর্থ হতে দেওয়া এবং সার্ভিস ম্যানেজারকে এটি আবার চালু করতে বলা, যেমন Restart=on-failure সঙ্গে RestartSec=5। প্রথমটি অনুপস্থিত পূর্বশর্তকে ব্যর্থ ইউনিট হিসেবে জানায়, দ্বিতীয়টি তা জানায় একগুচ্ছ রিস্টার্ট হিসেবে যা শেষে থেমে যায়; এটি জার্নালে বেশি শব্দ করে কিন্তু এমন ঠিকানা টিকে যায় যা আপনি অনুমান করতে পারেন না এমন কারণে দেরিতে আসে।

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

কেন network-online.target যথেষ্ট নয়

network-online.target সক্রিয় নেটওয়ার্ক বাস্তবায়ন online বলতে যা বোঝায় তা-ই প্রতিশ্রুতি দেয়, তার বেশি কিছু নয়। systemd-networkd-এর সাথে systemd-networkd-wait-online ঠিক করে কখন ওই লক্ষ্যে পৌঁছানো হয়, এবং online-এর তার পূর্বনির্ধারিত ধারণা আপনার নির্দিষ্ট ঠিকানা অস্তিত্বে আসার আগেই পূরণ হয়ে যেতে পারে। NetworkManager-এর অধীনে wait-online সার্ভিস তার নিজের নিয়ম প্রয়োগ করে। লক্ষ্যের পরে ক্রমবিন্যাস একটি সুস্থ ভিত্তিরেখা, কোনো এক ঠিকানা, DNS উত্তর বা দূরবর্তী সাথী প্রস্তুত—এমন নিশ্চয়তা নয়।

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

কোল্ড বুটের পরে বাইন্ডিং পরীক্ষা করুন

সার্ভিস রিস্টার্টের বদলে সত্যিকারের কোল্ড বুট দিয়ে যাচাই করুন, কারণ রিস্টার্ট এমন ঠিকানা উত্তরাধিকারে পায় যা বুট-ক্রমকে তৈরি করতে হয়েছিল। বুটের পরে ss -lntp বা ss -lunp প্রতিটি লিসেনার আসলে কোন লোকাল ঠিকানায় বাইন্ড হয়েছে তা দেখায়, আর journalctl -b -u openvpn-server@server দেখায় প্রথম চেষ্টাটি ব্যর্থ হয়েছিল কি না। বাইন্ড হওয়া ঠিকানাটি প্রোফাইলের ঠিকানার সাথে মিলান, তারপর নেটওয়ার্ক পুনরায় সংযুক্ত হওয়ার পরে মিলনটি আবার করুন।

প্রোফাইলে যদি কখনোই নির্দিষ্ট ঠিকানার দরকার না পড়ে, তবে local সরানো একটি বৈধ সরলীকরণ, কিন্তু এটি ট্রাবলশুটিং অভ্যাস নয়—নিরাপত্তার সিদ্ধান্ত বানান।

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

সম্পর্কিত নিবন্ধ