VPN सत्र टाइमर और प्रमाणीकरण टोकन अलग-अलग समाप्त होते हैं

VPN का कटना ऐसे कारणों से हो सकता है जो क्लाइंट की ओर से एक जैसे दिखते हैं और नीचे से कोई समानता नहीं रखते: टनल सत्र खत्म हो गया, निष्क्रियता टाइमर चल पड़ा, या जो क्रेडेंशियल क्लाइंट दोबारा इस्तेमाल कर रहा था वह पुराना पड़ गया। हर एक का मालिक अलग है और हल भी अलग है। कटने के क्षण की त्रुटियों का क्रम ही उन्हें अलग करता है, और वह आमतौर पर एक पंक्ति होती है।

एक टनल के खिलाफ तीन घड़ियाँ चलती हैं, और उनमें से सिर्फ एक ही टनल है।

एक टनल पर तीन अलग घड़ियाँ

सत्र की घड़ी गेटवे की है: अधिकतम कनेक्शन अवधि, निष्क्रियता की समय-सीमा या दोनों, और इनमें से कोई भी पूरा होने पर यह टनल बंद कर देती है। टोकन की घड़ी प्रमाणीकरण प्रणाली की है, और यह तय करती है कि बिना इंसान के कोई क्रेडेंशियल कितनी देर तक फिर पेश किया जा सकता है। रास्ते की घड़ी क्लाइंट और गेटवे के बीच बैठे किसी भी NAT या फायरवॉल की है, और यह उन प्रवाहों के मैपिंग समाप्त कर देती है जिन्हें वह पूरा मानती है। तीनों कटाव पैदा करते हैं, और कोई भी एक जैसी लॉग पंक्ति नहीं देता।

सिर्फ पहली VPN की अवधारणा है। बाकी दो पहचान और नेटवर्क से उधार ली गई हैं, और अक्सर उन्हें इससे मिला दिया जाता है।

टोकन असल में कैसे दोबारा इस्तेमाल होता है

OpenVPN सर्वर पहले लॉगिन के बाद प्रमाणीकरण टोकन जारी कर सकते हैं, इसलिए कंट्रोल-चैनल की दोबारा बातचीत उपयोगकर्ता से फिर क्रेडेंशियल नहीं मांगती। क्लाइंट वही टोकन पेश करता रहता है और सर्वर तय करता है कि वह कितनी देर स्वीकार्य रहता है। जब टोकन का जीवन दोबारा बातचीत के अंतराल से छोटा हो, तो अगली बातचीत विफल हो जाती है और क्लाइंट समय-सीमा की जगह प्रमाणीकरण त्रुटि बताता है। इसीलिए वही प्रोफ़ाइल एक घंटे काम करता है और फिर एक तय बिंदु पर विफल हो जाता है।

दोबारा बातचीत का अंतराल अलग सेटिंग है। इसे बदलने से यह खिसकता है कि टोकन कब पेश होता है, यह नहीं कि वह कितना जीता है।

क्लाइंट की ओर से हर समाप्ति कैसी दिखती है

सत्र की समय-सीमा आमतौर पर सर्वर की ओर के कारण के साथ साफ कटाव के रूप में आती है, अक्सर अनुमानित अवधि के बाद और बिना किसी प्रमाणीकरण त्रुटि के। निष्क्रियता की समय-सीमा खामोशी जैसी लगती है: टनल ट्रैफ़िक ढोना बंद कर देता है, फिर कीपअलाइव हार मान लेता है। टोकन की समाप्ति AUTH_FAILED के रूप में ऐसे सत्र के बीच आती है जो एक सेकंड पहले काम कर रहा था।

पंक्ति पढ़ें, फिर घड़ी देखें। सेट किए गए मान से मेल खाने वाली अवधि संयोग नहीं है।

सहेजा हुआ पासवर्ड क्यों मदद नहीं करता

कैश में रखा पासवर्ड पासवर्ड के चैलेंज का जवाब देता है। यह टोकन का जीवन नहीं बढ़ाता, और दूसरे कारक या डिवाइस की स्थिति की जाँच के चैलेंज को पूरा नहीं करता। दोबारा कोशिशों की आवृत्ति बढ़ाना, कनेक्शन की समय-सीमाएँ घटाना या प्रोफ़ाइल फिर आयात करना इस बात में कुछ नहीं बदलता कि पहचान प्रणाली क्रेडेंशियल को कितनी देर स्वीकार करेगी।

टिकाऊ हल सही वस्तु पर सही जीवनकाल है, या ऐसा क्लाइंट प्रवाह जो ज़रूरी चैलेंज बिना इंसान के पूरा कर सके।

क्या दस्तावेज़ करना और क्या जाँचना है

तीनों मान लिख लें: गेटवे की सत्र और निष्क्रियता सीमाएँ, टोकन का जीवनकाल, और रास्ते पर सबसे छोटी प्रासंगिक मैपिंग समय-सीमा। फिर एक मान छोटा करके हर समाप्ति जानबूझकर जाँचें, देखें कि क्लाइंट क्या बताता है, और मान वापस कर दें। हर सीमा पर उपयोगकर्ता को क्या करना है, इसकी पुष्टि करें, क्योंकि हर घंटे पूरा लॉगिन मांगना ऐसा नीति-निर्णय है जो किसी को जानबूझकर लेना चाहिए था।

बिना किसी प्रमाणीकरण घटना के आने वाला कटाव रास्ते का या निष्क्रियता टाइमर का होता है, और वह अलग सबूतों वाली अलग जाँच है।