VPN کنکشن کی حدود: زندہ حالت یا محفوظ تاریخ

ایک وقت میں تین کنکشن داخلے کا فیصلہ ہیں، اور اس کا جواب دینے کے لیے یہ جاننا ضروری ہے کہ ابھی کون سے سلاٹ بھرے ہوئے ہیں، نہ کہ پچھلے مہینے کیا ہوا۔ کوئی خدمت فعال ریکارڈ کی چھوٹی جدول سے چوتھا سیشن مسترد کر سکتی ہے اور کبھی ٹائم لائن نہیں بناتی۔ یہ طریقہ کار کے بارے میں بیان ہے، آپریٹر کے بارے میں نہیں، اور رازداری کی پالیسی پڑھتے وقت یہ فرق اہم ہے۔ نیچے کا ماڈل دکھاتا ہے کہ فیصلے کو کیا درکار ہے اور یہ کیا پھینک سکتا ہے۔

طریقہ کار: سلاٹ جدول، لاگ نہیں

سب سے سادہ عمل درآمد رکنیت کو زیادہ سے زیادہ تین فعال سیشن ریکارڈز سے جوڑتا ہے۔ ہر منظور شدہ سیشن ایک سلاٹ لیتا ہے، اور سلاٹ اس وقت خالی ہوتا ہے جب خدمت فیصلہ کرتی ہے کہ وہ سیشن ختم ہو گیا ہے۔ ریکارڈ کو اتنی مخصوص شناخت درکار ہے کہ ایک کنکشن چھوڑنے سے دوسرے کنکشن کا سلاٹ خالی نہ ہو؛ اسی لیے سیشن شناخت کنندہ اکاؤنٹ کے نام سے زیادہ اہم ہے۔

بھراؤ اور تاریخ مختلف ڈیٹا ڈھانچے ہیں۔ بھراؤ حال کے بارے میں ہاں-یا-نہیں سوال کا جواب دیتا ہے، اور سیشن ختم ہوتے ہی اسے پھینکا جا سکتا ہے۔ تاریخ صرف شامل ہونے والے واقعات کا بہاؤ ہے، اور یہ اس لیے قائم رہتی ہے کہ کسی نے اسے رکھنا چنا۔ کسی خدمت کے پاس ایک، دونوں یا کوئی بھی نہیں ہو سکتا۔

یہ فرق باہر سے نظر نہیں آتا۔ نظر آنے والی کنکشن حد میموری میں موجود چھوٹے شمار کنندہ، مشترکہ ڈیٹا بیس جدول اور ڈیش بورڈ والے مکمل واقعاتی محفوظے کے ساتھ مطابقت رکھتی ہے۔ حد کے بارے میں کچھ بھی نہیں بتاتا کہ ان میں سے کون چل رہا ہے۔

زندہ ماڈل کو اب بھی ہم آہنگی کیوں درکار ہے

گمشدہ کنکشن فوراً ختم شدہ تسلیم نہیں ہو سکتا۔ گیٹ وے وقت کی حد، keepalive کی ناکامی یا حساب بند ہونے کا انتظار کرتا ہے، اور جب تک ان میں سے کوئی نہ آئے سلاٹ بھرا رہتا ہے۔ اس دورانیے میں دوبارہ جڑنے والے صارف کو ایسی ردِ قبولیت ملتی ہے جس کا چوتھے آلے سے کوئی تعلق نہیں۔

دوبارہ شروع ہونے والے سرور کو اپنی حالت ہم آہنگ کرنی پڑتی ہے، اور ایک ہی اکاؤنٹ کی خدمت کرنے والے کئی گیٹ ویز کو مشترکہ فیصلہ درکار ہوتا ہے۔ ورنہ اکاؤنٹ مختلف مقامات سے جڑ کر اپنا کوٹہ عبور کر سکتا ہے۔ مشترکہ یا بحال ہو سکنے والی حالت اسے حل کرتی ہے، اور مشترکہ حالت ڈیزائن کی ضرورت ہے، نگرانی کا ثبوت نہیں۔

اس ہم آہنگی کے کسی حصے کو براؤزنگ تاریخ درکار نہیں۔ پیکٹ آگے بھیجنے والے گیٹ وے کو سیشن گننے کے لیے یہ جاننے کی ضرورت نہیں کہ سیشن نے کون سی سائٹیں دیکھیں، اور یہ دو ڈیٹا بہاؤ عام طور پر بالکل مختلف اجزا سنبھالتے ہیں۔

شمار میموری میں رکھنے سے متعلقہ حقائق گمنام بھی نہیں ہوتے۔ جب تک خدمت چلتی ہے، رکنیت سے منسلک ریکارڈ ظاہر کرتا ہے کہ اکاؤنٹ کے فعال کنکشن ہیں، اور اس حالت تک رسائی اور اس کی عمر دونوں پوچھنے کے قابل ہیں۔

وہ حالت آگے کہاں جاتی ہے

رازداری کا سوال یہ نہیں کہ سرور گن سکتا ہے یا نہیں۔ پوچھیں کہ ختم شدہ سیشن کا کیا ہوتا ہے: ریکارڈ ہٹا دیا جاتا ہے یا وہ نگرانی کی سلسلہ میں واقعہ بن جاتا ہے؟ پھر پوچھیں کہ وہی واقعہ کن دیگر اجزا نے دیکھا، کیونکہ توثیق کے لاگ، حسابی ریکارڈ اور بیک اپ ہر ایک وہ نقل رکھ سکتے ہیں جو نفاذ کے راستے نے پھینکی تھی۔

RADIUS حساب سب سے واضح مثال ہے۔ Start اور Stop کا جوڑا بلنگ اور سیشن کنٹرول کی معاونت کے لیے موجود ہے، اور یہ کنکشن کا ریکارڈ بناتا ہے، چاہے کوئی اسے کبھی تاریخ کے طور پر پوچھے یا نہ پوچھے۔ اس لیے حساب کے ذریعے حدود نافذ کرنے والی خدمت ساخت کے لحاظ سے سلاٹ جدول سے زیادہ رکھتی ہے۔

مٹانے کی بھی ایک شکل ہے۔ زندہ جدول سے ہٹایا گیا ریکارڈ ایک گھنٹہ پہلے لیے گئے بیک اپ میں قائم رہ سکتا ہے، اور اس بیک اپ کی حفاظت کی مدت اپنی الگ پالیسی کا بیان ہے۔ صرف بنیادی ذخیرہ پڑھنے سے نامکمل جواب ملتا ہے۔

سوال کو میدانوں کے لحاظ سے پوچھیں

RFC 6973 کی ڈیٹا کم کرنے کی رہنمائی جمع اور محفوظ کیے گئے ڈیٹا کو اس مقصد سے جوڑتی ہے جس کی خدمت کی جاتی ہے۔ یہاں لاگو کرنے پر، مفید سوال یہ ہے کہ بیک وقت داخلے کے کام کو حقیقتاً کون سے میدان درکار ہیں، اور اس کام کے ختم ہونے کے بعد ہر ایک کو رکھنے کا جواز کون سا مقصد فراہم کرتا ہے۔

درست خدمت کا بیان کوٹہ نافذ کرنے کے لیے استعمال ہونے والی زندہ کنکشن حالت کو خاتمے کے بعد رکھے گئے کسی بھی ریکارڈ سے الگ کرتا ہے، اور وعدے کے دائرے میں دیگر نظاموں کے نام لیتا ہے۔ صرف یہ کہنے والا جملہ کہ تین کنکشن نافذ کیے جاتے ہیں، نہ محفوظے کے ہونے اور نہ نہ ہونے کو ثابت کرتا ہے۔

جب زندگی کا چکر واضح نہ ہو، تو اسے فیصلے کے بجائے بغیر جواب والا حفاظتی سوال درج کریں۔ حد کا ہونا چھپی ہوئی تاریخ کا ثبوت نہیں، اور زندہ حالت کی معقول وضاحت فراہم کنندہ کی آڈٹ نہیں۔