VPN लॉगिन अलर्ट: उन्हें वास्तव में कौन-सी घटना ट्रिगर करनी चाहिए?
प्रमाणीकरण की सफलता, स्थापित टनल और RADIUS accounting Start तीन अलग-अलग दावे हैं। वह दावा चुनें जिस पर आपका प्राप्तकर्ता कार्य कर सके, फिर उन्हें सहसंबद्ध करें।
प्रमाणीकरण की सफलता, स्थापित टनल और RADIUS accounting Start तीन अलग-अलग दावे हैं, और लॉगिन ईमेल का अर्थ तभी होता है जब आप इनमें से एक चुनते हैं। ज़्यादातर VPN अलर्ट डिज़ाइन तीनों को मिला देते हैं और ऐसा इनबॉक्स बनाते हैं जिस पर कोई भरोसा नहीं करता। निर्णय इस पर निर्भर करता है कि अलर्ट कौन पढ़ता है और अगले पाँच मिनट में वह क्या कर सकता है। इसे गलत करने पर अलर्ट ऐसा शोर बन जाता है जो उस एक घटना को छिपा देता है जिसकी आपको ज़रूरत थी।
तीन सवाल ट्रिगर तय करते हैं
पूछें कि इसे कौन प्राप्त करेगा, वह क्या करेगा, और यह कार्रवाई कितनी तेज़ी से होनी चाहिए। क्रेडेंशियल के दुरुपयोग पर नज़र रखने वाली सुरक्षा टीम को एक खाते से कुछ ही मिनटों में विफल-फिर-सफल का पैटर्न चाहिए। क्षमता पर नज़र रखने वाली संचालन टीम को सत्र की अवधि और डिस्कनेक्ट के कारण चाहिए, लॉगिन नहीं। हेल्पडेस्क को सत्र की पहचान चाहिए ताकि वह टिकट से मिलान कर सके।
वे उत्तर अलग-अलग घटनाओं की ओर इशारा करते हैं, और कोई भी एक नियम तीनों को संतुष्ट नहीं करता। अगर प्राप्तकर्ता की कार्रवाई «उपयोगकर्ता को कॉल करें» है, तो प्रमाणीकरण पर्याप्त है। अगर कार्रवाई «लाइसेंस मुक्त करें» या «सत्यापित करें कि टनल ने ट्रैफ़िक ढोया» है, तो केवल स्थापना या accounting Start काम करेगा। अगर कार्रवाई «समय का बिल बनाएँ» है, तो आपको लॉगिन के बजाय Stop रिकॉर्ड चाहिए।
कुछ भी कॉन्फ़िगर करने से पहले उत्तर को एक वाक्य में लिखें। «यह ईमेल ऑन-कॉल इंजीनियर को बताता है कि खाते X ने समय Z पर नेटवर्क Y से टनल खोली, ताकि वह जाँच सके कि रखरखाव विंडो का उपयोग हुआ या नहीं।» अगर आप हर जगह नहीं भर सकते, तो ट्रिगर अभी चुना नहीं गया है।
घटना को उस दावे से मिलाएँ जो आप कर रहे हैं
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
तालिका एक निर्भरता छिपाती है: हर पंक्ति तभी भरोसेमंद है जब गेटवे उसे विश्वसनीय रूप से जारी करे और आपका संग्राहक वह फ़ील्ड रखे जो आपको चाहिए। आप जो सटीक संस्करण चलाते हैं उसके लिए घटना की परिभाषा पढ़ें, क्योंकि «सत्र स्थापित» नाम संस्करणों के बीच बदलता है और अर्थ नाम से अधिक बार बदलता है। जब परिभाषा अस्पष्ट हो, तो लेबल से अनुमान लगाने के बजाय सत्र कैप्चर माँगें।
Access-Accept को उसके बाद की हर चीज़ के पूरा होने के रूप में लेना सबसे आम गलती है। यह क्रेडेंशियल पर फ़ैसला है, सत्र नहीं। उलटी गलती नीति मिलान को प्राधिकरण का प्रमाण पढ़ना है, जबकि नियम मिल सकता है और अगला कदम फिर भी विफल हो सकता है।
एक सत्र, एक सूचना
एक खाता, कई डिवाइस, पुनःप्रेषण और पुनःकनेक्शन: हर घटना पर एक ईमेल दोनों दिशाओं में गलत होगा, एक सत्र की नकल करेगा जबकि दूसरे को बाँट देगा। सूचना की कुंजी गेटवे और सत्र पहचानकर्ता पर रखें, और खाते के नाम को कुंजी नहीं बल्कि विशेषता मानें। लैपटॉप और फ़ोन वाले उपयोगकर्ता के पास एक साथ दो टनल हो सकते हैं, और दोनों अपनी अलग पंक्ति के हक़दार हैं।
पुनःप्रेषित लेखा रिकॉर्ड सामान्य हैं, इसलिए संदेश प्रस्तुत करने से पहले सत्र आईडी और टाइमस्टैम्प पर डुप्लिकेट हटाएँ। एक ही डिवाइस के लगातार सत्र अलग रहने चाहिए, और रखरखाव विंडो के दौरान पुनःकनेक्शन पिछले में समा जाने के बजाय दिखाई देना चाहिए। अगर आपका संग्राहक अंतर्ग्रहण पर टाइमस्टैम्प फिर से लिखता है, तो संग्रहीत फ़ील्ड पर नहीं, मूल रिकॉर्ड के फ़ील्ड पर डुप्लिकेट हटाएँ।
गुम Stop रिकॉर्ड अनिश्चितता है, स्थायी सत्र नहीं। गेटवे रीबूट, संग्राहक रुकावट और UDP हानि सभी अंतराल छोड़ते हैं, इसलिए अलर्ट को ऐसा समाधान पथ चाहिए जो किसी के यह निष्कर्ष निकालने से पहले कि टनल अभी भी चालू है, जीवित सत्र तालिका से पूछे।
ऑडिट और सूचना अलग रखें
ऑडिट स्ट्रीम और अलर्ट स्ट्रीम के काम अलग हैं। कच्चे रिकॉर्ड रखें, जिनमें खाता, गेटवे, सत्र आईडी, टाइमस्टैम्प और समाप्ति का कारण शामिल है, तब भी जब नियमित ईमेल समूहित, दबाए या छोटी ऑन-कॉल सूची पर भेजे जाएँ। गंभीरता की सीमा एक डिलीवरी फ़िल्टर है, उस जीवनचक्र घटना का चयन नहीं जिसकी आप घोषणा करना चाहते थे।
प्राप्तकर्ता को संरक्षित रिकॉर्ड खोजने के लिए ज़रूरी न्यूनतम संदर्भ भेजें। खाता नाम, आंतरिक पते और सत्र विवरण संवेदनशील हैं, और जो ईमेल अच्छी तरह अग्रेषित होता है वही अच्छी तरह लीक भी होता है।
फिर इसे शुरू से अंत तक सिद्ध करें। सामान्य लॉगिन और लॉगआउट, एक पुनःकनेक्शन, दो एक साथ सत्र और एक ज़बरदस्ती डिलीवरी विफलता चलाएँ, और गेटवे से संग्राहक होते हुए दिए गए संदेश तक एक घटना का पता लगाएँ। अगर ईमेल सत्र आईडी के बिना पहुँचे, तो अनुबंध अधूरा है। अगर दो ईमेल एक सत्र का वर्णन करें, तो सहसंबंध टूटा है। जब आप केवल यह परखते हैं कि मेल डिलीवरी काम करती है, तब दोनों में से कोई समस्या दिखाई नहीं देती।