মাসিক ডেটা কোটা OpenVPN অ্যাকাউন্টে কোথায় থাকা উচিত

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

কোটা টানেলে নয়, অ্যাকাউন্টে বেঁধে দিন

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

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

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

একক, দিক ও রিসেট সীমা ঠিক করুন

যেকোনো সংগ্রহ শুরুর আগে চারটি সংজ্ঞা লিখিতভাবে ঠিক করতে হবে। কোটা কি ক্লায়েন্ট যে বাইট পাঠায়, যে বাইট গ্রহণ করে, নাকি দুটির যোগফল গণনা করে? এক গিগাবাইট কি 10^9 বাইট নাকি 2^30? কোন স্থানীয় ঘণ্টায় এবং কোন সময় অঞ্চলে সময়কাল পাল্টায়? এবং কাউন্টারটি ঠিক কী মাপে, যেহেতু টানেলের অতিরিক্ত ভার ও পুনঃপ্রেরণ অন্তর্ভুক্ত, কিন্তু অ্যাপ্লিকেশন ফাইলের আকার ও সরবরাহকারীর চালান নয়?

এই কোনো বিকল্পই ভুল নয়, তবে বাস্তবায়ন ও গ্রাহকের সামনের সংখ্যাটি মিলতে হবে। একই সিস্টেমের দুই অর্ধেক GiB নিয়ে, বা স্থানীয় সময়ের বদলে UTC মধ্যরাতে ঘটা পরিবর্তন নিয়ে একমত না হলে ঠিক সেই ধরনের টিকিট তৈরি হয় যা পুরো কোটা সম্পর্কে আস্থা নষ্ট করে।

বাইট মোটকে একটিতে চার্জ করা ডেল্টায় পরিণত করুন

ম্যানেজমেন্ট ইন্টারফেস পর্যায়ক্রমিক BYTECOUNT_CLI লাইন রিপোর্ট করে, যেগুলো একটি ক্লায়েন্ট আইডি এবং প্রতি দিকে ক্রমপুঞ্জিত বাইট মোট বহন করে, আর bytecount কমান্ড ঠিক করে সেগুলো কত ঘন ঘন আসে। সার্ভারের দৃষ্টিকোণ থেকে, গৃহীত সংখ্যাটি ক্লায়েন্টের পাঠানো বাইট গণনা করে এবং প্রেরিত সংখ্যাটি তার কাছে পৌঁছানো বাইট গণনা করে। ব্যবধানটি এমন কিছুতে সেট করুন যা লেজার হজম করতে পারে; খুব ছোট ব্যবধান এমন নিখুঁততা কেনে যা আপনি আসলে পান না।

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

rx_delta = sample.rx_now - session.prev_rx
tx_delta = sample.tx_now - session.prev_tx
charge  = rx_delta + tx_delta
# same transaction:
ledger.total += charge
session.prev_rx, session.prev_tx = sample.rx_now, sample.tx_now

নতুন ভিত্তিরেখা ও ব্যবহারের বৃদ্ধি একসাথে নিশ্চিত করুন, যাতে একটি নমুনা পুনরায় চালালে দুবার চার্জের বদলে কিছুই চার্জ না হয়। পিছনে সরোয়া কাউন্টার একটি সংকেত, ঋণ নয়: এর অর্থ সেশনটি প্রতিস্থাপিত হয়েছে বা ডেমন পুনরায় চালু হয়েছে, এবং সঠিক প্রতিক্রিয়া হলো ঋণাত্মক পরিমাণ জমা না দিয়ে সেশন পরিচয় মিলিয়ে নেওয়া।

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

ক্লান্তি যেন প্রবেশ প্রত্যাখ্যান করে, শুধু টানেল না মারে

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

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

টোকেন-ভিত্তিক পুনঃসংযোগ নিজস্ব পরীক্ষার দাবিদার। OpenVPN 2.6 auth-gen-token দিয়ে অভ্যন্তরীণভাবে একটি সেশন টোকেন যাচাই করতে পারে, আপনার নিয়ন্ত্রক সীমা প্রয়োগে যে বাহ্যিক প্রমাণীকরণ কল ব্যবহার করত তা এড়িয়ে। তাই এখনো বৈধ একটি টোকেন পরিচয় প্রমাণ করে, অবশিষ্ট কোটা নয়, এবং প্রতিটি নতুন ক্লায়েন্ট ইনস্ট্যান্সকে এখনো লেজারের সাথে পরামর্শ করতে হবে। এর বদলে management-client-auth চালু করলে নিয়ন্ত্রকই প্রমাণীকর্তা হয়ে যায় এবং সেশন অবস্থা বিশ্লেষণ করে মেয়াদোত্তীর্ণ বা অবৈধ টোকেন নিজে প্রত্যাখ্যানের দায়িত্ব উত্তরাধিকারে পায়।

নমুনায়ন যে অতিক্রম তৈরি করে তা মেনে নিন

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

প্রকৃত কঠিন সিলিং ভিন্ন একটি প্রকৌশল সমস্যা: ফরোয়ার্ডিং পথের ভেতরে প্রয়োগ, সেশন জুড়ে একই অ্যাকাউন্টে বাঁধা। কাউন্টার দ্রুত পড়া একই জিনিস নয়, এবং এটি এমন ক্লায়েন্টকে টিকিয়ে রাখে না যে শুধু আরও টানেল খোলে।

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