VPN कनेक्शन सीमाएँ: जीवंत स्थिति बनाम संग्रहित इतिहास
तीन कनेक्शन की सीमा के लिए जीवंत स्लॉट स्थिति चाहिए, ब्राउज़िंग इतिहास नहीं: तंत्र को क्या संग्रहित करना चाहिए, क्या छोड़ सकता है, और वह स्थिति आगे कहाँ जाती है।
तीन साथ-साथ कनेक्शन एक प्रवेश निर्णय हैं, और उसका उत्तर देने के लिए यह जानना ज़रूरी है कि इस समय कौन-से स्लॉट भरे हुए हैं, न कि पिछले महीने क्या हुआ था। कोई सेवा सक्रिय रिकॉर्ड की एक छोटी तालिका से चौथा सत्र अस्वीकार कर सकती है और कभी कोई समयरेखा नहीं बनाती। यह तंत्र के बारे में कथन है, संचालक के बारे में नहीं, और गोपनीयता नीति पढ़ते समय यह अंतर मायने रखता है। नीचे का मॉडल दिखाता है कि निर्णय को क्या चाहिए और यह क्या छोड़ सकता है।
तंत्र: स्लॉट तालिका, लॉग नहीं
सबसे सरल कार्यान्वयन किसी सदस्यता को अधिकतम तीन सक्रिय सत्र रिकॉर्ड से जोड़ता है। हर स्वीकृत सत्र एक स्लॉट लेता है, और स्लॉट तब मुक्त होता है जब सेवा तय करती है कि वह सत्र समाप्त हो गया है। रिकॉर्ड को इतनी विशिष्ट पहचान चाहिए कि एक कनेक्शन मुक्त करने से दूसरे कनेक्शन का स्लॉट मुक्त न हो; इसीलिए सत्र पहचानकर्ता खाता नाम से अधिक महत्वपूर्ण है।
अधिभोग और इतिहास भिन्न डेटा संरचनाएँ हैं। अधिभोग वर्तमान के बारे में हाँ-या-ना वाले प्रश्न का उत्तर देता है, और सत्र समाप्त होते ही उसे छोड़ा जा सकता है। इतिहास केवल जोड़े जाने वाली घटनाओं की धारा है, और वह इसलिए बचा रहता है कि किसी ने उसे रखना चुना। किसी सेवा के पास एक, दोनों या कोई भी नहीं हो सकता।
यह भेद बाहर से अदृश्य है। दिखाई देने वाली कनेक्शन सीमा मेमोरी में रखे एक छोटे काउंटर, साझा डेटाबेस तालिका और डैशबोर्ड वाले पूर्ण घटना संग्रह के साथ संगत है। सीमा के बारे में कुछ भी आपको नहीं बताता कि इनमें से कौन चल रहा है।
| What is stored | Why it exists |
|---|---|
| Active session slots | To admit or refuse the next connection |
| Session event log | To investigate or bill later |
| Monitoring series | To watch capacity and error rates |
| Backup copies | To restore any of the above |
जीवंत मॉडल को अब भी समन्वय की आवश्यकता क्यों है
हो सकता है कि खोया हुआ कनेक्शन तुरंत समाप्त पहचाना न जाए। गेटवे किसी टाइमआउट, keepalive विफलता या लेखांकन स्टॉप की प्रतीक्षा करता है, और जब तक उनमें से कोई न आए स्लॉट भरा रहता है। जो उपयोगकर्ता उस अवधि में फिर जुड़ता है, उसे ऐसा इनकार मिलता है जिसका चौथे उपकरण से कोई संबंध नहीं है।
पुनः आरंभ किए गए सर्वर को अपनी स्थिति मिलानी पड़ती है, और एक ही खाते की सेवा करने वाले कई गेटवे को साझा निर्णय चाहिए। अन्यथा कोई खाता अलग-अलग स्थानों से जुड़कर अपना कोटा पार कर सकता है। साझा या पुनःप्राप्य स्थिति इसे हल करती है, और साझा स्थिति डिज़ाइन की आवश्यकता है, निगरानी का प्रमाण नहीं।
इस समन्वय के किसी भी भाग के लिए ब्राउज़िंग इतिहास नहीं चाहिए। पैकेट आगे भेजने वाले गेटवे को सत्र गिनने के लिए यह जानने की ज़रूरत नहीं कि किसी सत्र ने कौन-सी साइटें देखीं, और इन दो डेटा धाराओं को सामान्यतः पूरी तरह अलग घटक संभालते हैं।
मेमोरी में गिनती रखने से जुड़े तथ्य गुमनाम भी नहीं हो जाते। जब तक सेवा चलती है, सदस्यता से जुड़ा रिकॉर्ड प्रकट करता है कि किसी खाते के सक्रिय कनेक्शन हैं, और उस स्थिति तक पहुँच तथा उसका जीवनकाल दोनों पूछने योग्य हैं।
वह स्थिति आगे कहाँ जाती है
गोपनीयता का प्रश्न यह नहीं है कि सर्वर गिन सकता है या नहीं। पूछें कि समाप्त सत्र का क्या होता है: रिकॉर्ड हटा दिया जाता है, या वह निगरानी श्रृंखला में एक घटना बन जाता है? फिर पूछें कि किस अन्य घटक ने वही घटना देखी, क्योंकि प्रमाणीकरण लॉग, लेखांकन रिकॉर्ड और बैकअप प्रत्येक ऐसी प्रति रख सकते हैं जिसे प्रवर्तन मार्ग ने छोड़ दिया था।
RADIUS लेखांकन सबसे स्पष्ट उदाहरण है। Start और Stop की जोड़ी बिलिंग और सत्र नियंत्रण का समर्थन करने के लिए होती है, और वह कनेक्शन का रिकॉर्ड बनाती है, चाहे कोई उसे कभी इतिहास के रूप में पूछे या न पूछे। इसलिए लेखांकन के माध्यम से सीमाएँ लागू करने वाली सेवा रचना के अनुसार स्लॉट तालिका से अधिक रखती है।
मिटाने का भी एक रूप है। जीवंत तालिका से हटाया गया रिकॉर्ड एक घंटे पहले लिए गए बैकअप में बना रह सकता है, और उस बैकअप की प्रतिधारण अवधि अपने आप में एक नीति कथन है। केवल प्राथमिक भंडार पढ़ने से अधूरा उत्तर मिलता है।
प्रश्न को फ़ील्ड के रूप में पूछें
RFC 6973 का डेटा-न्यूनीकरण मार्गदर्शन एकत्र और संग्रहित डेटा को उस उद्देश्य से जोड़ता है जिसकी सेवा की जाती है। यहाँ लागू करने पर उपयोगी प्रश्न यह है कि साथ-साथ प्रवेश का कार्य वास्तव में किन फ़ील्ड की आवश्यकता रखता है, और कौन-सा उद्देश्य उस कार्य के समाप्त होने के बाद प्रत्येक को रखने को उचित ठहराता है।
एक सटीक सेवा कथन कोटा लागू करने के लिए प्रयुक्त जीवंत कनेक्शन स्थिति को समाप्ति के बाद रखे गए किसी भी रिकॉर्ड से अलग करता है, और वादे के दायरे में अन्य प्रणालियों के नाम गिनाता है। केवल यह कहने वाला वाक्य कि तीन कनेक्शन लागू किए जाते हैं, न यह सिद्ध करता है कि कोई संग्रह है, न यह कि कोई नहीं है।
जब जीवनचक्र स्पष्ट न हो, तो उसे निर्णय के बजाय अनुत्तरित प्रतिधारण प्रश्न के रूप में दर्ज करें। सीमा का होना छिपे इतिहास का प्रमाण नहीं है, और जीवंत स्थिति की प्रशंसनीय व्याख्या प्रदाता का अंकेक्षण नहीं है।