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 हानी सर्व अंतर ठेवतात, म्हणून सूचनेला अशी समेटाची वाट हवी जी कोणीही टनेल अजून सुरू आहे असा निष्कर्ष काढण्यापूर्वी थेट सत्र तक्त्याला विचारते।
ऑडिट आणि सूचना वेगळे ठेवा
ऑडिट प्रवाह आणि सूचना प्रवाहाची कामे वेगळी आहेत। खाते, गेटवे, सत्र आयडी, टाइमस्टॅम्प आणि समाप्तीचे कारण यासह कच्च्या नोंदी ठेवा, अगदी नेहमीचे ईमेल गटबद्ध, दाबले किंवा लहान ऑन-कॉल यादीवर पाठवले गेले तरी। तीव्रतेची मर्यादा ही वितरण गाळणी आहे, तुम्ही जाहीर करू इच्छित असलेल्या जीवनचक्र घटनेची निवड नाही।
संरक्षित नोंद शोधण्यासाठी प्राप्तकर्त्याला आवश्यक असलेला किमान संदर्भ पाठवा। खात्याची नावे, अंतर्गत पत्ते आणि सत्र तपशील संवेदनशील आहेत, आणि चांगले फॉरवर्ड होणारा ईमेल चांगला गळणारा ईमेल असतो।
मग ते सुरुवातीपासून शेवटपर्यंत सिद्ध करा। सामान्य लॉगिन आणि लॉगआउट, एक पुनःकनेक्शन, दोन एकाच वेळची सत्रे आणि सक्तीचा वितरण बिघाड चालवा, आणि गेटवेपासून संग्राहकातून पोहोचवलेल्या संदेशापर्यंत एक घटना शोधा। सत्र आयडीशिवाय ईमेल आला तर करार अपूर्ण आहे। दोन ईमेल एका सत्राचे वर्णन करत असतील तर सहसंबंध तुटलेला आहे। तुम्ही फक्त मेल वितरण चालते का हेच तपासत असाल तेव्हा या दोन्ही समस्या दिसत नाहीत।