ক্লায়েন্ট হুক নাকি সার্ভার হুক? OpenVPN স্ক্রিপ্ট কোথায় চলে

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

দুটি মেশিন, প্রথমে উত্তর দেওয়ার মতো দুটি প্রশ্ন

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

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

দুটির আগে তৃতীয় একটি প্রশ্ন করা উচিত: প্ল্যাটফর্মটি আদৌ আপনার চাওয়া হুকটি দেয় কি? যে অ্যাপ্লায়েন্স নিজের কনফিগারেশন নিজেই তৈরি করে সেটি একই ইভেন্টের নাম নাও দিতে পারে, আর যে ডেস্কটপ ক্লায়েন্ট একটি .ovpn ফাইল আমদানি করে সেটি অবশ্যই সেই ক্লায়েন্ট নয় যার জন্য ফাইলটি লেখা হয়েছিল। প্ল্যাটফর্ম আগে নিশ্চিত করলে সেখানে না থাকা হুককে ঘিরে ডিজাইন করার ঝামেলা থেকে বাঁচবেন। এটি আরও বলে দেয় কোন ডকুমেন্টেশন সত্যিই আপনার সামনের মেশিনে প্রযোজ্য।

সার্ভার-পক্ষের বিকল্প: প্রতি-সংযোগে একটি ইভেন্ট

একটি client-connect স্ক্রিপ্ট সার্ভারের প্রক্রিয়া প্রসঙ্গে চলে যখন একটি প্রমাণিত ক্লায়েন্ট সংযোগ করে, এবং এটি common name ও বরাদ্দ করা ঠিকানা-র মতো নথিভুক্ত সংযোগের বিবরণ পায়। প্রতি-ক্লায়েন্ট কনফিগারেশন খণ্ড লেখা, নীতি-সিদ্ধান্ত প্রয়োগ করা বা সার্ভারের মালিকানার স্টেট লিপিবদ্ধ করার সঠিক জায়গা এটি।

মানুষ যে পার্থক্যটি মিস করে তা হলো এই হুক ও সার্ভার up হুকের মধ্যে পার্থক্য। up হুকটি চালু হয় যখন সার্ভার তার টানেল ডিভাইস খোলে, যা বহু-ক্লায়েন্ট সার্ভারে ডেমন শুরুর সময় একবারই ঘটে। এটি প্রতি-লগইন ইভেন্ট নয়, আর সেখানে রাখা কোড ব্যবহারকারীরা সংযোগ করার সময় নয়, বরং সার্ভিস শুরুর সময় চলে।

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

ক্লায়েন্ট-পক্ষের বিকল্প: যে কাজ স্থানীয়ভাবে চলতেই হবে

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

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

নামকরণও গুরুত্বপূর্ণ। up হুক ডিভাইস তৈরির সঙ্গে মেলে এবং route-up রুট ইনস্টলের সঙ্গে, কিন্তু যে কাজের জন্য বেসরকারি নেটওয়ার্ক পৌঁছানোর মতো হওয়া দরকার, তা ডিভাইস তৈরি মানেই প্রতিটি রুট, রিজলভার এন্ট্রি ও অ্যাপ্লিকেশন প্রস্তুত—এমন ধরে নেওয়ার বদলে পৌঁছানোর ক্ষমতা যাচাই করা উচিত।

কেন চালনযোগ্য কোড push করা বিকল্পের তালিকায় নেই

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

স্থানীয়ভাবে স্ক্রিপ্ট চালানো সক্ষম করলে তা বদলায় না। আপনার script-security সেটিং আপনি বেছে নেওয়া স্থানীয় স্ক্রিপ্টের অনুমতি দেয়; এটি সার্ভারকে নতুন স্ক্রিপ্ট সরবরাহ করার অধিকার দেয় না।

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

দুটির যেকোনো হুক বিশ্বাস করার আগে কী যাচাই করবেন

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

যে অ্যাকাউন্ট সত্যিই এটি চালাবে তার অধীনেই পরীক্ষা করুন, যে মুহূর্তে সত্যিই এটি চলবে সেই মুহূর্তে। openvpn(8) ম্যানুয়াল দুটি হুক পরিবার ও push সীমাবদ্ধতা নথিভুক্ত করে; আপনি যে প্ল্যাটফর্মে স্থাপন করছেন তা নথিভুক্ত করে এটি আদৌ সেগুলো দেয় কি না। ইন্টারঅ্যাকটিভ অ্যাডমিনিস্ট্রেটর টার্মিনালে সফল হওয়া স্ক্রিপ্ট একটি অনুমান, যাচাই নয়।