VPN कनेक्शन मर्यादा: थेट स्थिती की साठवलेला इतिहास

तीन एकाच वेळची कनेक्शन हा प्रवेशाचा निर्णय आहे, आणि त्याला उत्तर देण्यासाठी गेल्या महिन्यात काय झाले हे नव्हे, तर आत्ता कोणते स्लॉट भरले आहेत हे माहीत असणे आवश्यक आहे। सेवा सक्रिय नोंदींच्या छोट्या तक्त्यातून चौथे सत्र नाकारू शकते आणि कधीही कालरेषा तयार करत नाही। हे यंत्रणेबद्दलचे विधान आहे, ऑपरेटरबद्दल नाही, आणि गोपनीयता धोरण वाचताना हा फरक महत्त्वाचा असतो। खालील प्रतिमान निर्णयाला काय हवे आणि काय टाकून देता येईल हे दाखवते।

यंत्रणा: स्लॉट तक्ता, लॉग नाही

सर्वात सोपी अंमलबजावणी वर्गणीला जास्तीत जास्त तीन सक्रिय सत्र नोंदींशी जोडते। प्रत्येक स्वीकारलेले सत्र एक स्लॉट घेते, आणि सेवेने ते सत्र संपले असे ठरविल्यावर स्लॉट मोकळा होतो। एक कनेक्शन सोडल्यावर दुसऱ्या कनेक्शनचा स्लॉट मोकळा होऊ नये यासाठी नोंदीला पुरेशी विशिष्ट ओळख हवी; म्हणून सत्र ओळखकर्ता खात्याच्या नावापेक्षा अधिक महत्त्वाचा आहे।

भरलेलेपण आणि इतिहास या वेगवेगळ्या माहिती रचना आहेत। भरलेलेपण वर्तमानाबद्दलच्या होय-की-नाही प्रश्नाचे उत्तर देते, आणि सत्र संपताच त्या क्षणी ते टाकून देता येते। इतिहास हा केवळ जोडला जाणारा घटनांचा प्रवाह आहे, आणि कोणीतरी तो ठेवायचे ठरविल्यामुळे तो टिकतो। सेवेकडे एक, दोन्ही किंवा यापैकी काहीही नसू शकते।

हा फरक बाहेरून अदृश्य आहे। दिसणारी कनेक्शन मर्यादा मेमरीतील लहान मोजणीसह, सामायिक डेटाबेस तक्त्यासह आणि डॅशबोर्ड असलेल्या संपूर्ण घटना संग्रहासह सुसंगत आहे। मर्यादेबद्दल काहीही कोणते चालू आहे हे सांगत नाही।

थेट प्रतिमानाला अजूनही समन्वय का हवा

हरवलेले कनेक्शन लगेच संपले असे ओळखले जाणार नाही। गेटवे टाइमआउट, keepalive अपयश किंवा लेखा थांबण्याची वाट पाहतो, आणि त्यापैकी एक येईपर्यंत स्लॉट भरलेला राहतो। त्या कालावधीत पुन्हा जोडणाऱ्या वापरकर्त्याला चौथ्या उपकरणाशी काहीही संबंध नसलेला नकार मिळतो।

पुन्हा सुरू केलेल्या सर्व्हरला त्याची स्थिती जुळवावी लागते, आणि एकाच खात्याला सेवा देणाऱ्या अनेक गेटवेजना सामाईक निर्णय हवा असतो। अन्यथा खाते वेगवेगळ्या ठिकाणी जोडून आपला कोटा ओलांडू शकते। सामायिक किंवा पुनर्प्राप्य स्थिती हे सोडवते, आणि सामायिक स्थिती ही रचना-आवश्यकता आहे, देखरेखीचा पुरावा नाही।

त्या समन्वयाच्या कोणत्याही भागाला ब्राउझिंग इतिहास हवा नसतो। पॅकेट पुढे पाठवणाऱ्या गेटवेला सत्रे मोजण्यासाठी सत्राने कोणत्या साइटला भेट दिली हे माहीत असणे आवश्यक नाही, आणि हे दोन माहिती प्रवाह सामान्यतः पूर्णपणे वेगळे घटक हाताळतात।

मोजणी मेमरीत ठेवल्याने संबंधित तथ्ये अज्ञातही होत नाहीत। सेवा चालू असताना वर्गणीशी जोडलेली नोंद खात्याला सक्रिय कनेक्शन आहेत हे उघड करते, आणि त्या स्थितीपर्यंतचा प्रवेश व त्याचे आयुष्य दोन्ही विचारण्याजोगे आहेत।

ती स्थिती पुढे कुठे जाते

गोपनीयतेचा प्रश्न सर्व्हर मोजू शकतो का हा नाही। संपलेल्या सत्राचे काय होते ते विचारा: नोंद काढली जाते की ती देखरेख मालिकेतील घटना बनते? नंतर तीच घटना कोणत्या इतर घटकांनी पाहिली ते विचारा, कारण प्रमाणीकरण नोंदी, लेखा नोंदी आणि बॅकअप प्रत्येक अंमलबजावणी मार्गाने टाकून दिलेली प्रत ठेवू शकतात।

RADIUS लेखा हे सर्वात स्पष्ट उदाहरण आहे। बिलिंग आणि सत्र नियंत्रणाला आधार देण्यासाठी Start आणि Stop जोडी असते, आणि कोणी ती कधी इतिहास म्हणून विचारते की नाही याची पर्वा न करता ती कनेक्शनची नोंद तयार करते। म्हणून लेखामार्फत मर्यादा लागू करणारी सेवा रचनेनुसार स्लॉट तक्त्यापेक्षा अधिक ठेवते।

हटवण्यालाही एक आकार असतो। थेट तक्त्यातून काढलेली नोंद एक तास आधी घेतलेल्या बॅकअपमध्ये टिकू शकते, आणि त्या बॅकअपचा धारण कालावधी हा स्वतंत्र धोरण विधान आहे। केवळ प्राथमिक साठा वाचल्यास अपूर्ण उत्तर मिळते।

प्रश्न क्षेत्रांच्या दृष्टीने विचारा

RFC 6973 चे माहिती-किमानीकरण मार्गदर्शन संकलित आणि साठवलेली माहिती सेवा दिल्या जाणाऱ्या उद्देशाशी जोडते। येथे लागू केल्यास, उपयुक्त प्रश्न असा आहे की एकाच वेळच्या प्रवेशाच्या कार्याला प्रत्यक्षात कोणती क्षेत्रे हवी आहेत, आणि ते कार्य संपल्यानंतर प्रत्येक ठेवण्याचे समर्थन कोणता उद्देश देतो।

अचूक सेवा विधान कोटा लागू करण्यासाठी वापरली जाणारी थेट कनेक्शन स्थिती समाप्तीनंतर ठेवल्या जाणाऱ्या कोणत्याही नोंदींपासून वेगळी करते, आणि वचनाच्या व्याप्तीतील इतर प्रणालींची नावे घेते। केवळ तीन कनेक्शन लागू केली जातात असे सांगणारे वाक्य संग्रह आहे किंवा नाही हे दोन्हीपैकी काहीही सिद्ध करत नाही।

जेव्हा जीवनचक्र अस्पष्ट असेल, तेव्हा ते निर्णय न म्हणता अनुत्तरित धारण प्रश्न म्हणून नोंदवा। मर्यादा असणे हा छुप्या इतिहासाचा पुरावा नाही, आणि थेट स्थितीचे संभाव्य स्पष्टीकरण हे पुरवठादाराचे लेखापरीक्षण नाही।