OpenVPN ক্লায়েন্ট পুনঃসংযোগ: তিনটি নিয়ন্ত্রণ, তিনটি পরিধি

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

কোন নিয়ন্ত্রণ ব্যবহার করবেন তা জিজ্ঞাসা করার আগে জিজ্ঞাসা করুন কে প্রভাবিত হবে।

একটি ইনস্ট্যান্স: ব্যবস্থাপনা ইন্টারফেস

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

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

UDP প্রস্থান বিজ্ঞপ্তি কোনো একক ক্লায়েন্টের কমান্ড নয়

explicit-exit-notify হলো প্রস্থান ও পুনরায় চালু হওয়ার ঘটনা নিয়ে একটি কনফিগারেশন নির্দেশিকা। UDP ক্লায়েন্টে এটি সহকর্মীকে জানায় যে সেশনটি শেষ হচ্ছে, আর সংখ্যাসূচক আর্গুমেন্ট নিয়ন্ত্রণ করে বিজ্ঞপ্তিটি কতবার পুনরায় পাঠানো হবে। সার্ভার যখন UDP-তে চলে তখন এটি সংযুক্ত ক্লায়েন্টদের পুনরায় চালুর নিয়ন্ত্রণ বার্তা পাঠায়, আর নথিভুক্ত মানগুলো একই সার্ভারে পুনঃসংযোগ এবং অন্য রিমোট এন্ট্রিতে যাওয়ার মধ্যে পার্থক্য করে। এটি বৃহৎ শ্রোতার জন্য একটি জীবনচক্র সংকেত।

এর ভেতরে কিছুই খেয়ালখুশি মতো কোনো মুহূর্তে কোনো ক্লায়েন্ট বেছে নেয় না। এটিকে পুনঃসংযোগ বোতাম হিসেবে ব্যবহার করলে একসাথে প্রতিটি সংযুক্ত সেশনে পৌঁছে যায়।

সিগন্যাল প্রক্রিয়ার উপর কাজ করে, সেশনের উপর নয়

SIGUSR1 চলমান প্রক্রিয়াকে কনফিগারেশন না পড়েই তার সংযোগ পুনরায় চালু করতে বলে, আর স্থায়িত্বের অপশনগুলো ঠিক করে এই পুনরায় চালুর পর কী টিকে থাকবে। SIGHUP আরও এগিয়ে যায়: এটি কনফিগারেশন ফাইল আবার পড়ে এবং নিজের রিসোর্স আবার খোলে। SIGTERM এবং SIGINT সুশৃঙ্খল বন্ধের অনুরোধ করে। এগুলো প্রক্রিয়া-স্তরের কাজ: বহু-ক্লায়েন্ট সার্ভারে এগুলো প্রক্রিয়ার বহন করা প্রতিটি সেশনকে প্রভাবিত করে, টিকিটে উল্লিখিত সেশনটিকে নয়।

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

নিয়ন্ত্রণ বেছে নেওয়ার আগে পরিধি ঠিক করুন

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

পুনঃসংযোগ বোতাম পেতে একটি অপ্রমাণিত নিয়ন্ত্রণ লিসেনার যোগ করা পোর্টে পৌঁছাতে পারে এমন যে কেউকে সেই বোতামের চেয়ে অনেক বেশি দিয়ে দেয়।

নতুন সেশন যাচাই করুন, বিচ্ছিন্নতা নয়

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

পরিবর্তনের রেকর্ডে পরিধিটি লিখুন। 'ক্লায়েন্ট পুনঃসংযোগ করেছি' কোনো বর্ণনা নয় যখন ক্লায়েন্টটি শেয়ার করা সার্ভারে চল্লিশজনের একজন ছিল।