VPN সংযোগ সীমা: জীবিত অবস্থা বনাম সংরক্ষিত ইতিহাস

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

প্রক্রিয়া: স্লট সারণি, লগ নয়

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

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

পার্থক্যটি বাইরে থেকে অদৃশ্য। একটি দৃশ্যমান সংযোগ সীমা ছোট ইন-মেমরি কাউন্টার, ভাগ করা ডেটাবেস সারণি এবং ড্যাশবোর্ডসহ পূর্ণ ঘটনা আর্কাইভের সাথে সামঞ্জস্যপূর্ণ। সীমা সম্পর্কে কিছুই বলে না কোনটি চলছে।

কেন জীবিত মডেলের এখনও সমন্বয় দরকার

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

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

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

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

অবস্থাটি পরে কোথায় যায়

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

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

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

প্রশ্নটি ক্ষেত্রের পরিভাষায় করুন

RFC 6973-এর ডেটা-ন্যূনতমকরণ নির্দেশনা সংগৃহীত ও সংরক্ষিত ডেটাকে যে উদ্দেশ্যে সেবা দেওয়া হচ্ছে তার সাথে বাঁধে। এখানে প্রয়োগ করলে উপযোগী প্রশ্ন হলো একসাথে-প্রবেশের কাজটির আসলে কোন ক্ষেত্রগুলো দরকার, এবং সেই কাজ শেষ হওয়ার পরে প্রতিটি রাখার যৌক্তিকতা কী উদ্দেশ্য দেয়।

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

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