OpenVPN-এর up স্ক্রিপ্টটি কি খুব আগে চলেছিল, নাকি এটি কখনোই প্রস্তুত হয়নি?

up স্ক্রিপ্টটি চলে, শূন্য নিয়ে বের হয়, আর তার ভেতরের কাজটি এমন একটি ব্যক্তিগত সেবায় পৌঁছাতে ব্যর্থ হয় যা দুই সেকেন্ড পরে টার্মিনাল থেকে নিখুঁতভাবে কাজ করে। সহজ অনুমান হলো সময়ের সমস্যা, আর স্বাভাবিক সমাধান হলো ঘুম, যা না বুঝেই প্রতিযোগিতাটি লুকিয়ে রাখে। আরও কাজের ব্যাখ্যা হলো, “up” একটি হুকের নাম, প্রস্তুতির নিশ্চয়তা নয়। টানেল ডিভাইস কনফিগার হলে এটি চালু হয়, যা রুট, DNS এবং অবশ্যই টানেলের পিছনের যেকোনো অ্যাপ্লিকেশনের চেয়ে আগে।

শেলের পরীক্ষাটি সফল হয়েছিল কারণ এটি সবকিছু থেমে যাওয়ার পরে চলেছিল। হুকটি একটি নির্দিষ্ট মুহূর্তে চলেছিল।

স্টার্টআপ ক্রমে up কোথায় অবস্থান করে

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

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

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

হুকটি আসলে কী উত্তরাধিকার পায়

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

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

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

কেন ঘুম যোগ করা প্রস্তুতির পরীক্ষা নয়

ঘুম স্ক্রিপ্টটিকে বিলম্বিত করে এবং প্রতিযোগিতার জানালা সরিয়ে দেয়। দ্রুত দিনে কাজটি সফল হয়; ধীর দিনে আবার ব্যর্থ হয়, এবং ব্যর্থতা পুনরুৎপাদন করা কঠিন হয় কারণ বিলম্বটি কাজ করছে বলে মনে হয়। যে বিলম্ব কেবল হালকা লোডে কাজ করে তা কাকতালীয়, প্রতিকার নয়।

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

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

পরিষ্কার করা এবং পুনঃসংযোগ একই যত্নের দাবিদার

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

পুনঃসংযোগগুলো পূর্ণ সেবা শুরুর চেয়ে বেশি বার হুক চালাতে পারে। যে স্থায়ী ইন্টারফেস সেশন পুনঃপ্রতিষ্ঠা করে তা up ও route-up চক্র আবার চালু করতে পারে, তাই প্রতি বুটে একবার সম্পাদন ধরে নেওয়া স্ক্রিপ্ট শেষে ভুল আচরণ করবে। এক দিনের কম্পনের লগে সম্পাদনগুলো গুনে দেখুন এটি আসলে কতবার চলে। তারপর স্ক্রিপ্টটিকে এতবার চালানোর জন্য নিরাপদ করুন।

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

প্রতিটি কাজ যে ইভেন্টের উপর নির্ভর করে তার নাম দিন, তারপর এটিকে সেই ইভেন্টে যুক্ত করুন। বাকি সবকিছু পরীক্ষার ভান করা বিলম্ব।