OpenVPN /24 কেন প্রত্যাশার চেয়ে দ্রুত ক্লায়েন্ট ফুরিয়ে যায়

/24-এর উপর নির্মিত পুলগুলো যখন ষাটের কাছাকাছি ক্লায়েন্ট নেওয়া বন্ধ করে, তখন সেগুলো ডিজাইন অনুযায়ীই কাজ করছে, কোনো লাইসেন্স সীমায় পৌঁছাচ্ছে না। net30-এ প্রতিটি ক্লায়েন্টকে একটি ভার্চুয়াল পয়েন্ট-টু-পয়েন্ট লিঙ্ক দেওয়া হয় যা চারটি ঠিকানা খায়, তাই 256 ঠিকানার একটি সাবনেট প্রিফিক্স যা ইঙ্গিত দেয় তার প্রায় এক চতুর্থাংশ সমর্থন করে। গুরুত্বপূর্ণ সংখ্যা হলো বরাদ্দ, ঠিকানা নয়। প্রিফিক্সকে ক্লায়েন্ট সংখ্যা হিসেবে পড়াই সেই ভুল যা লুকানো ব্যবহারকারী সীমার খোঁজ তৈরি করে।

দুটি টপোলজি, দুটি গাণিতিক মডেল, এবং তাদের মধ্যে কেবল একটি মানুষ যা ধরে নেয় সেই প্রিফিক্সের সঙ্গে মেলে।

net30 প্রতি ক্লায়েন্টে চারটি ঠিকানা ব্যয় করে

net30 প্রতি ক্লায়েন্টে একটি /30 ব্লক বরাদ্দ করে, কারণ প্রতিটি সেশনকে উভয় প্রান্তে ঠিকানাসহ একটি পয়েন্ট-টু-পয়েন্ট লিঙ্ক হিসেবে মডেল করা হয়। সেই ব্লকে চারটি ঠিকানা যায় এবং দুটি ব্যবহারযোগ্য, তাই কার্যকর ক্লায়েন্ট সংখ্যা সাবনেটের এক চতুর্থাংশ। একটি /24-এ এটি সার্ভারের নিজস্ব ব্লক ও যেকোনো নির্দিষ্ট বরাদ্দ বের হওয়ার আগে 64টি ব্লক রেখে দেয়। 63-এর কাছাকাছি রিপোর্ট করা সিলিং হলো প্রকাশ পাচ্ছে এমন গাণিতিক হিসাব, কোনো কনফিগার করা সর্বোচ্চ নয়।

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

পুলের সীমানা প্রিফিক্সের চেয়ে বেশি গুরুত্বপূর্ণ

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

সক্ষমতা সম্পর্কে কিছু সিদ্ধান্তে আসার আগে দুটো তুলনা করুন, কারণ ছোট কনফিগার করা পরিসর টপোলজির মতোই ভালোভাবে সিলিং ব্যাখ্যা করে।

যে সীমা সত্যিই ক্লায়েন্টকে প্রত্যাখ্যান করেছে তা খুঁজুন

প্রথমে টপোলজি ও কার্যকর পুল পড়ুন, তারপর নির্দিষ্ট বরাদ্দ ও সংরক্ষিত ঠিকানার হিসাব করুন। এছাড়া max-clients এবং OpenVPN-এর বাইরের যেকোনো প্রবেশ নিয়ন্ত্রণ ঠিকানা স্থানকে দোষ দেওয়ার আগে দেখে নিন। সবশেষে, প্রত্যাখ্যানের মুহূর্তে সার্ভারের নিজের বার্তাটি সেই প্রার্থীদের সঙ্গে মিলিয়ে দেখুন। বার্তাটি সীমাবদ্ধতার নাম বলে; সংখ্যা কেবল পরিধি সংকীর্ণ করে।

একযোগে সংযোগের ত্রুটিসহ আসা প্রত্যাখ্যান আর বরাদ্দ ত্রুটিসহ আসা প্রত্যাখ্যানের সংশোধন আলাদা, আর তাদের মধ্যে অনুমান করা একটি রক্ষণাবেক্ষণ উইন্ডো নষ্ট করে।

টপোলজি বদলালে ঠিকানা পরিকল্পনা বদলায়

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

এই বদল পুরোনো কনফিগারেশনের সমার্থক নয়। এটিকে নিজস্ব পর্যালোচনাসহ একটি ঠিকানা-পরিকল্পনা পরিবর্তন হিসেবে দেখুন, এবং অন্তত একটি ক্লায়েন্ট আগের স্কিমের ঠিকানা ধরে রাখবে বলে আশা করুন।

মাস্ক থেকে নয়, পরিকল্পনা থেকে পুলের আকার নির্ধারণ করুন

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

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