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