OpenVPN-এর একাধিক --up স্ক্রিপ্ট সতর্কতা: চলে কেবল একটি

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

তাই সতর্কতাটি গুরুত্ব পাওয়ার যোগ্য, যদিও এটি মারাত্মক নয়: এটি যা পূর্বাভাস দেয় তা হলো এমন একটি DNS আপডেট বা রুট পরিবর্তন যা চুপচাপ ঘটনা বন্ধ করে দিয়েছে।

সতর্কতাটি ক্রম নিয়ে নয়

OpenVPN up ধাপের জন্য একটি একক ব্যবহারকারী-স্ক্রিপ্ট কমান্ড রাখে। পার্সার যখন প্রোফাইল, অন্তর্ভুক্ত ফাইল বা কমান্ড লাইন থেকে আরেকটি সংজ্ঞা পায়, তখন সে যা ধরে রেখেছিল তা প্রতিস্থাপন করে এবং সতর্কতা দেয়। কিছুই একসাথে জোড়া হয় না, কিছুই দুইবার চলে না, এবং ক্রম নিয়ে কোনো প্রশ্নই নেই। যে কমান্ডটি টিকে থাকে সেটি পার্সারের সর্বশেষ দেখা কমান্ড, তাই একটি লাইন সরালে বিজয়ী বদলাতে পারে এবং অন্য স্ক্রিপ্টটি মৃত থেকে যায়।

একই ধরন অন্য স্ক্রিপ্ট ধাপেও প্রযোজ্য: প্রতিটিতে একটি কমান্ড। যদি দুটি কাজ একসাথেই ঘটতে হয়, তবে তাদের একটি প্রবেশবিন্দু দরকার, তালিকার মতো দেখতে দুটি নির্দেশ নয়।

প্রকৃত লঞ্চে দুটি সংজ্ঞাই খুঁজুন

আপনি সম্পাদনা করেছেন এমন প্রোফাইল থেকে নয়, ডেমনটি আসলে যা পেয়েছে তা থেকে শুরু করুন। ps -ef এবং ইউনিটের ExecStart কমান্ড লাইন দেখায়, যেখানে কনটেইনার এন্ট্রিপয়েন্ট বা মোড়ক স্ক্রিপ্ট থেকে --up যোগ হতে পারে; ডিস্ট্রিবিউশনের init ফাইলও একই কাজ করতে পারে। systemctl cat openvpn-server@server দেখায় সার্ভিসটি নিজে কী অবদান রাখে, আর কনফিগারেশন ডিরেক্টরিতে পুনরাবৃত্ত grep ফাইল-স্তরের সংজ্ঞা খুঁজে বের করে। নকল সাধারণত ভিন্ন স্তর থেকে আসে, আর এক ফাইল সম্পাদনা করলে কিছুই বদলায় না — কারণ ঠিক এটাই।

স্ক্রিপ্ট অন্য ডিরেক্টরিতে কপি করা বা নাম বদলানোও কোনো নির্দেশ মুছে দেয় না। পার্সার ফাইল নয়, সংজ্ঞা গোনে।

একটি hook-ই কাজটির মালিক হোক

টেকসই সমাধান হলো একটি একক ডিসপ্যাচার যা দুটি কাজ সচেতন ক্রমে চালায়। set -eu সহ একটি ছোট shell স্ক্রিপ্ট প্রয়োজনীয় ইন্টিগ্রেশন এবং তারপর স্থানীয় কাজটি ডাকে, এবং আর্গুমেন্টের সীমা টিকিয়ে রাখতে "$@" পাস করে; এতে আচরণ একটিই যাচাইযোগ্য জায়গায় থাকে। আর্গুমেন্ট পাস করা কেবল সেগুলো সংরক্ষণ করে; দুটি সহায়ক একই ইন্টারফেস আশা করে বলে তা প্রমাণ করে না, তাই প্রতিটির চুক্তি পড়ুন। ব্যর্থতা কী করবে এবং আংশিক পরিবর্তন ফেরানো দরকার কি না তা ঠিক করুন।

লঞ্চার যদি সমর্থিত এক্সটেনশন hook দেয়, তবে হাতে গড়া চেইনের বদলে সেটিই বেছে নিন। কনটেইনার ইমেজ বা ভেন্ডর প্যাকেজে অতিরিক্ত কাজের জন্য প্রায়ই নথিভুক্ত জায়গা থাকে, এবং তা ব্যবহার করলে আপগ্রেড আপনার ডিসপ্যাচারকে লিখে মুছে দিতে পারে না।

পরিষ্কার করা সংশ্লিষ্ট down ধাপের কাজ। DNS পুনর্লিখন বা রুট যোগ করা একটি up কাজের নথিভুক্ত প্রত্যাবর্তন দরকার, আর যে ডিসপ্যাচার কেবল শুরু সামলায় তা অর্ধেক নকশা।

নীরবতা নয়, ইন্টিগ্রেশন নিশ্চিত করুন

নকল সতর্কতা সরানো সহজ অংশ; ইন্টিগ্রেশনকে এখনো কাজ করতে হবে। সংযোগের পর resolvectl status দিয়ে বা /etc/resolv.conf পড়ে রিজলভারের অবস্থা যাচাই করুন, এবং ip route দিয়ে রুট নিশ্চিত করুন। তারপর সংযোগ বিচ্ছিন্ন করে আবার যুক্ত হন, কারণ তাড়াহুড়ো করে জোড়া hook আগের সেশনের কিছু রেখে যায়। journalctl -u openvpn-server@server -b দেখায় আপনার ডিসপ্যাচার চলেছিল কি না এবং কী ছাপিয়েছিল।

hook-এর বিশেষাধিকার যেখানে থাকা উচিত সেখানেই রাখুন। script-security বাড়ানো বা ডেমনকে বেশি অধিকার দিয়ে চালানো প্রতিস্থাপিত hook-এর সমাধান নয়; এটি ভবিষ্যতের প্রতিটি স্ক্রিপ্টের সামর্থ্য বাড়ায়, এমনকি আক্রমণকারীর নাম দেওয়া স্ক্রিপ্টেরও।

সমাধানটি সত্যি হওয়ার চিহ্ন লগে নীরবতা নয়। চিহ্ন হলো DNS উত্তর, রুট এন্ট্রি এবং পরিষ্কার করা — দুবার পুনঃসংযোগের পর সবগুলো ঠিকভাবে কাজ করা।