শুধু একটি ম্যানেজমেন্ট ক্লায়েন্ট: কেন আপনার মনিটর GUI-কে বের করে দেয়
ম্যানেজমেন্ট সকেট একবারে একটি মাত্র সংযোগ নেয়। দ্বিতীয় সাবস্ক্রাইবার হয় যুক্ত হতে ব্যর্থ হয়, নয়তো প্রম্পট ধারণকারী উপাদান থেকে নিয়ন্ত্রণ কেড়ে নেয়।
একটি ডেস্কটপ GUI ম্যানেজমেন্ট সংযোগ ধরে রাখে, তাই একটি মনিটরিং স্ক্রিপ্ট নিজের সংযোগ খোলার চেষ্টা করে এবং কিছুই পড়ে না, বা আরও খারাপ, GUI প্রম্পটের উত্তর দেওয়া বন্ধ করে দেয়। স্বাভাবিক সিদ্ধান্ত হয় যে ডেমনটি অস্থির। কমিউনিটি ডেমনে এই সীমাবদ্ধতা ইচ্ছাকৃত: কন্ট্রোল ইন্টারফেস একবারে কেবল একটি সংযুক্ত ম্যানেজমেন্ট ক্লায়েন্টকে সেবা দেয়, এবং এই সংখ্যার সাথে VPN কতজন ব্যবহারকারী বহন করতে পারে তার কোনো সম্পর্ক নেই।
এক সকেট, এক ধারক
ম্যানেজমেন্ট চ্যানেল একটি সংযুক্ত ক্লায়েন্ট গ্রহণ করে। প্রথমটি সক্রিয় থাকার সময় দ্বিতীয়টি এলে সেটি অপেক্ষা করে বা প্রত্যাখ্যাত হয়, এবং কোনো অপশনের পিছনে সমান্তরাল সাবস্ক্রাইবার মোড লুকিয়ে নেই। বর্তমান ধারকের সংযোগ বিচ্ছিন্ন করলে ডেমন পরবর্তীটি গ্রহণ করে, এবং এটি দ্বিতীয় চ্যানেল নয়, একটি হস্তান্তর।
এতে প্রতিটি অতিরিক্ত টুল প্রতিযোগী হয়ে ওঠে। যদি GUI সংযোগের মালিক হয়, তবে পোলিং স্ক্রিপ্ট হয় যুক্ত হতে ব্যর্থ হয়, নয়তো GUI হেরে যাওয়ার পরেই সফল হয়, এবং পরবর্তী পুনঃসংযোগে এই ক্রম আবার ঘটে। যদি স্ক্রিপ্ট আগে যুক্ত হয়, তবে GUI তার নিয়ন্ত্রণ পথ হারায় এবং তার প্রম্পটগুলো কাজ করা বন্ধ করে দেয়। কোনো টুলই এই সংঘর্ষের রিপোর্ট করে না, কারণ প্রত্যেকে কেবল নিজের ব্যর্থ কমান্ড দেখে।
| What you need | Mechanism that fits | What it cannot do |
|---|---|---|
| Periodic list of connected clients | Status file written on an interval | Deliver events as they happen |
| Interactive prompts and session control | The single management connection | Serve two controllers at once |
| Multiple consumers of either | One owner process that fans out | Exist without you writing it |
কোন উপাদান নিয়ন্ত্রণের মালিক তা নির্ধারণ করুন
ইন্টার্যাকটিভ চ্যানেলের জন্য একজন মালিক বাছুন এবং তাকেই সংযুক্ত হওয়ার একমাত্র জিনিস হতে দিন। সংযোগ পরিচালনা করা GUI, প্রমাণীকরণ প্রম্পটের উত্তর দেওয়া স্ক্রিপ্ট এবং সেশন সমাপ্ত করা কন্ট্রোলার, সবাই মালিক হিসেবে গণ্য হয়, এবং কেবল একজনই এই ভূমিকা নিতে পারে।
যখন GUI সংযোগের মালিক হয়, তখন তার সাথে লড়াই না করে সেই GUI যে ইন্টিগ্রেশন দেয় তা ব্যবহার করুন। সকেটের জন্য মালিকের সাথে প্রতিযোগিতা করলে মাঝে মাঝে ব্যর্থতা তৈরি হয় যা ব্যবহারকারীদের কাছে এলোমেলো মনে হয়, এবং সমস্যা অনুসন্ধানকারী সাধারণত দৌড়ের কেবল দ্বিতীয়ার্ধ দেখেন। রিবুটের পরে কোন প্রক্রিয়া আগে যুক্ত হয় তা খেয়াল করুন, কারণ সেই ক্রমই প্রতিবার কে জিতবে তা নির্ধারণ করে। GUI-এর আগে শুরু হওয়া মনিটর GUI হার না মানা পর্যন্ত চ্যানেলটি ধরে রাখবে।
সংগ্রাহকদের জন্য স্থিতি স্ন্যাপশট ব্যবহার করুন
বেশিরভাগ মনিটরিংয়ের জন্য তালিকা দরকার, কথোপকথন নয়। একটি পর্যায়ক্রমিক স্থিতি ফাইল কন্ট্রোল চ্যানেল স্পর্শ না করেই এর উত্তর দেয়, এবং GUI সংযুক্ত থাকাকালীনও কাজ করতে থাকে।
status /run/openvpn/server.status 10
management /run/openvpn/server.sock unixব্যবধান হলো সতেজতার বাজেট, তাই এটি ড্যাশবোর্ডের প্রকৃত প্রয়োজন অনুযায়ী ঠিক করুন, নিরাপদ মনে হওয়া ক্ষুদ্রতম মান অনুযায়ী নয়। প্রতি কয়েক সেকেন্ডে লেখা স্ন্যাপশট সস্তা; প্রতি কয়েক সেকেন্ডে কন্ট্রোল সকেটে পুনঃসংযোগ করা স্ক্রিপ্ট সস্তা নয়, কারণ প্রতিটি পুনঃসংযোগ মালিকের সাথে প্রতিযোগিতা করে।
স্ন্যাপশট কোনো ইতিহাস নয় এবং ঘটনা প্রবাহও নয়। একটি ব্যবধানের ভিতরে এসে চলে যাওয়া সংযোগগুলো কখনো দেখা যায় না, তাই নিজের উপর পুনরায় লেখা একটি ফাইল পোল করে নিরীক্ষার প্রয়োজন পূরণ করা যায় না। ব্যবহারকারী আদৌ সংযুক্ত হয়েছিল কি না তা যদি জানতে চান, তবে স্ন্যাপশট ভুল যন্ত্র।
ফ্যান-আউট একটি নকশা, মোড নয়
যদি একাধিক গ্রাহকের সত্যিই লাইভ ম্যানেজমেন্ট ডেটা দরকার হয়, তবে সকেটের সামনে একটি বিশ্বস্ত উপাদান রাখুন এবং তাকে সযত্নে বাছাই করা পর্যবেক্ষণ বাকিদের কাছে প্রকাশ করতে দিন। ওই উপাদানই পুনঃসংযোগ, প্রমাণীকরণ প্রম্পট এবং কী প্রকাশ করা নিরাপদ সেই সিদ্ধান্তের মালিক।
এটি সচেতনভাবে তৈরি করুন: কোন কোয়েরিগুলো অনুমোদিত তা নির্ধারণ করুন, কে জিজ্ঞাসা করেছে তা লগ করুন, এবং ফ্যান-আউট স্তরকে অনিচ্ছাকৃতভাবে রিমোট কন্ট্রোল প্যানেলে পরিণত করা এড়িয়ে চলুন। ডেমনে সক্রিয় করার মতো কোনো মাল্টি-ক্লায়েন্ট মোড নেই, এবং কোনো কনফিগারেশন লাইন তা তৈরি করে না। মালিককে নিরাপত্তা সীমানার অংশ হিসেবে দেখুন, কারণ তার হাতে এমন ইন্টারফেস আছে যা মানুষকে বিচ্ছিন্ন করতে পারে। এটি পুনরায় চালু করা নথিভুক্ত পুনরুদ্ধার পথসহ একটি রুটিন কাজ হওয়া উচিত।
সকেটকে বিশেষাধিকার হিসেবে দেখুন, মেট্রিক হিসেবে নয়
ম্যানেজমেন্ট ইন্টারফেস ব্যবহারকারীদের বিচ্ছিন্ন করতে পারে, অবস্থা পরিবর্তন করতে পারে এবং মানুষের নাম থাকা ঘটনা পড়তে পারে। এর পাসওয়ার্ড ক্লায়েন্টকে প্রমাণীকরণ করে এবং পরিবহন এনক্রিপ্ট করে না, তাই নেটওয়ার্কে শ্রবণকারী যে কেউ কথোপকথন দেখতে পায় তার সামনে তা উন্মুক্ত করে দেয়।
স্থানীয় সকেট বা কঠোরভাবে সীমিত শ্রবণকারীকে অগ্রাধিকার দিন, এবং পরীক্ষা করুন আপনার সংগ্রাহক আসলে কোন প্রক্রিয়াকে সম্বোধন করছে, কারণ সার্ভার পণ্যগুলো তাদের নিজস্ব ম্যানেজমেন্ট API নিয়ে আসে যা ভিন্নভাবে আচরণ করে। ভুল ডেমনকে দেখানো সংগ্রাহক আত্মবিশ্বাসী কিন্তু ভুল সিদ্ধান্ত তৈরি করে। কিছুই ফেরত দেয় না এমন কোয়েরি ডিবাগ করার আগে পথ এবং মালিক প্রক্রিয়া নিশ্চিত করুন।