VPN सत्र टाइमर आणि प्रमाणीकरण टोकन स्वतंत्रपणे संपतात

VPN तुटणे अशा कारणांनी होऊ शकते जी क्लायंटच्या बाजूने एकसारखी दिसतात आणि आतून काहीही समाईक नसतात: टनल सत्र संपले, निष्क्रियता टाइमर सुरू झाला, किंवा क्लायंट पुन्हा वापरत असलेले क्रेडेन्शियल जुने झाले। प्रत्येकाचा मालक वेगळा आणि उपाय वेगळा आहे। तुटण्याच्या क्षणीचा त्रुटींचा क्रमच त्यांना वेगळा करतो, आणि तो सहसा एक ओळ असतो।

एका टनलविरुद्ध तीन घड्याळे चालतात, आणि त्यातली फक्त एकच टनल आहे।

एका टनलवर तीन वेगळी घड्याळे

सत्राचे घड्याळ गेटवेचे आहे: जास्तीत जास्त जोडणी कालावधी, निष्क्रियता कालमर्यादा किंवा दोन्ही, आणि त्यातले कोणतेही गाठले की ते टनल संपवते। टोकनचे घड्याळ प्रमाणीकरण प्रणालीचे आहे, आणि माणसाशिवाय क्रेडेन्शियल किती काळ पुन्हा सादर करता येईल हे ते ठरवते। मार्गाचे घड्याळ क्लायंट आणि गेटवेमध्ये असलेल्या कोणत्याही NAT किंवा फायरवॉलचे आहे, आणि संपलेले मानले जाणारे प्रवाह यांचे मॅपिंग ते संपवते। तिन्ही जोडणी तुटण्यास कारणीभूत होतात, आणि एकही समान लॉग ओळ देत नाही।

फक्त पहिलीच VPN संकल्पना आहे। उरलेली दोन ओळख आणि नेटवर्कमधून घेतलेली आहेत, आणि त्यांना अनेकदा त्याच्याशी गल्लत केली जाते।

टोकन प्रत्यक्षात कसे पुन्हा वापरले जाते

OpenVPN सर्व्हर पहिल्या लॉगिननंतर प्रमाणीकरण टोकन देऊ शकतात, त्यामुळे कंट्रोल-चॅनेलची पुनर्बोलणी वापरकर्त्याकडे पुन्हा क्रेडेन्शियल मागत नाही। क्लायंट ते टोकन सादर करत राहतो आणि सर्व्हर ते किती काळ स्वीकारार्ह राहते हे ठरवतो। टोकनचे आयुष्य पुनर्बोलणीच्या अंतरापेक्षा कमी असल्यास पुढील पुनर्बोलणी अपयशी होते, आणि क्लायंट कालमर्यादेऐवजी प्रमाणीकरण त्रुटी कळवतो। म्हणूनच तोच प्रोफाइल एक तास चालतो आणि नंतर ठराविक बिंदूवर अपयशी होतो।

पुनर्बोलणीचे अंतर वेगळी सेटिंग आहे। ते बदलल्याने टोकन कधी सादर होते ते सरकते, ते किती काळ जगते ते नाही।

क्लायंटकडून प्रत्येक समाप्ती कशी दिसते

सत्राची कालमर्यादा सहसा सर्व्हरच्या बाजूच्या कारणासह स्वच्छ तुटणे म्हणून येते, बऱ्याचदा अंदाजे कालावधीनंतर आणि कोणत्याही प्रमाणीकरण त्रुटीशिवाय। निष्क्रियतेची कालमर्यादा शांततेसारखी वाटते: टनल रहदारी वाहून नेणे थांबवते, मग कीपअलाइव्ह हार मानते। टोकनची समाप्ती AUTH_FAILED म्हणून अशा सत्राच्या मध्यभागी येते जे एक सेकंद आधी चालू होते।

ओळ वाचा, मग घड्याळाकडे पहा। सेट केलेल्या मूल्याशी जुळणारा कालावधी योगायोग नाही।

जतन केलेला पासवर्ड का मदत करत नाही

कॅशेमधील पासवर्ड पासवर्डसाठीच्या आव्हानाला उत्तर देतो। तो टोकनचे आयुष्य वाढवत नाही, आणि दुसऱ्या घटकाच्या किंवा उपकरणाच्या स्थितीच्या तपासणीचे आव्हान पूर्ण करत नाही। पुन्हा प्रयत्नांची वारंवारता वाढवणे, जोडणीच्या कालमर्यादा कमी करणे किंवा प्रोफाइल पुन्हा आयात करणे यामुळे ओळख प्रणाली क्रेडेन्शियल किती काळ स्वीकारेल यात काहीही बदलत नाही।

टिकाऊ उपाय म्हणजे योग्य वस्तूवर योग्य आयुष्य, किंवा माणसाशिवाय आवश्यक आव्हान पूर्ण करू शकणारा क्लायंट प्रवाह।

काय दस्तऐवजीकरण करावे आणि काय तपासावे

तीनही मूल्ये लिहा: गेटवेच्या सत्र आणि निष्क्रियता मर्यादा, टोकनचे आयुष्य, आणि मार्गावरील सर्वात लहान संबंधित मॅपिंग कालमर्यादा। मग एक मूल्य कमी करून प्रत्येक समाप्ती जाणूनबुजून तपासा, क्लायंट काय कळवतो ते पहा, आणि मूल्य पुन्हा बसवा। प्रत्येक सीमेवर वापरकर्त्याने काय करावे याची पुष्टी करा, कारण दर तासाला पूर्ण लॉगिन मागणे हा अशी धोरणात्मक निर्णय आहे जो कोणीतरी जाणूनबुजून घ्यायला हवा होता।

कोणत्याही प्रमाणीकरण घटनेशिवाय येणारे तुटणे मार्गाचे किंवा निष्क्रियता टाइमरचे असते, आणि ती वेगळ्या पुराव्यांसह वेगळी तपासणी आहे।