तासन्तास चाललेली बोगदा लॅपटॉप जागा होण्याच्या क्षणी पासवर्ड मागते, आणि संरचनेत काहीही बदलले नाही. बदलले ते पुन्हा कनेक्टने पुन्हा वापरण्याचा प्रयत्न केलेल्या ओळखपत्राची स्थिती. तीन प्रकारची सामग्री हे नियंत्रित करते, आणि त्यापैकी फक्त एकच कोणतेही अंतर टिकून राहते.

क्लायंटने कोणती मागितली ते वाचा, कारण तिन्ही वेगवेगळ्या घड्याळांनी संपतात आणि वेगवेगळ्या संदेशांसह अपयशी होतात.

पुन्हा वापरता येणारी तीन प्रकारची सामग्री

कॅशेमधील पासवर्ड हे क्लायंटकडे असलेले रहस्य आहे, आणि खाते तो बदलेपर्यंत तो वैध राहतो. सत्र टोकन यशस्वी लॉगिननंतर सर्व्हर देतो, त्याला स्वतःचे आयुष्य असते आणि कोणत्याही क्षणी रद्द करता येते. TLS सत्र तिकीट किंवा IKE सुरक्षा संबंध ही प्रोटोकॉल स्थिती आहे, पुन्हा सुरू करण्यास स्वस्त आणि तुमच्या पासवर्डपासून पूर्णपणे स्वतंत्र. प्रत्येक वेगळा घटक देतो, आणि प्रत्येक स्वतःच्या अटींवर संपतो.

पहिले रीबूट टिकून राहते, दुसरे सहसा सस्पेंड टिकून राहते, आणि तिसरे नेटवर्क बदलात कदाचित अजिबात टिकणार नाही. हे एकत्र करणे चुकीचा उपाय देते, उदाहरणार्थ कधीही नाकारला न गेलेला पासवर्ड रीसेट करणे.

सूचना स्वतःच निदान आहे. ब्राउझर विंडो किंवा दुसऱ्या घटकाचा कोड म्हणजे सर्व्हरने परस्परसंवादी प्रमाणीकरण मागितले, तर सूचनेशिवाय शांत अपयश म्हणजे क्लायंट विचारले जाण्याइतका पुढे गेलाच नाही.

MaterialTypical lifetimeWhat invalidates it
Cached passwordUntil changedAccount or password policy change
Session tokenMinutes to hoursExpiry, revocation, reauthentication policy
Tunnel SA or TLS ticketConfigured rekey intervalRekey, network change, peer restart

की नूतनीकरण म्हणजे पुन्हा प्रमाणीकरण नाही

की नूतनीकरण प्रमाणित ओळख टिकवून की बदलते, म्हणून निरोगी बोगद्यावर ते अधूनमधून शांतपणे घडते. पुन्हा प्रमाणीकरण ओळख तपासणीच पुन्हा करते, आणि तुमची गरज असलेली घटना तीच आहे. IKEv2 दोन्ही स्पष्टपणे वेगळे करते, आणि सहकारी दरम्यान कितीही की नूतनीकरणे झाली तरी ठरलेल्या अंतराने पूर्ण पुन्हा प्रमाणीकरण मागू शकतो. लॉग कोणत्या घटनेचे नाव घेतो हे वाचण्यापर्यंत दोन्ही घटना बाहेरून सारख्याच दिसतात.

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

म्हणून आठ तासांनंतरचे पुन्हा कनेक्शन आठ मिनिटांनंतरचे पुन्हा कनेक्शन यशस्वी झालेल्या ठिकाणी अपयशी होऊ शकते, दोन्ही बाजूंना कोणताही संरचना बदल न करता. दुपारच्या जेवणानंतरच दिसणाऱ्या सूचनेचे संपूर्ण स्पष्टीकरण हेच आहे.

क्लायंटला नवे आव्हान पूर्ण करता येत नसताना

ब्राउझर पाऊल मागणारे धोरण ते दाखवण्याचा मार्ग नसलेल्या क्लायंटवर अपयशी होईल. हेडलेस सर्व्हर, स्टार्टअप स्क्रिप्ट आणि फक्त पासवर्ड प्रमाणीकरणासाठी बनवलेल्या जुन्या प्रोफाइल्स सर्व त्या भिंतीवर आदळतात, आणि अपयश बहुतेक वेळा प्रमाणीकरण त्रुटीऐवजी सामान्य कालमर्यादा म्हणून दिसते.

उपकरण आणि नेटवर्क संक्रमणे देखील धोरण मूल्यांकनाच्या खिडकीत येऊ शकतात, त्यामुळे Wi-Fi वरून हॉटस्पॉटकडे जाणे हे तसेही होणाऱ्या तपासणीशी जुळते. हा योगायोग नेटवर्कला दोषी दाखवतो जेव्हा कारण टाइमर असते.

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

पहिली ओळ क्लायंटच्या स्वतःच्या लॉगमधील पुन्हा बोलणी आणि प्रमाणीकरणाच्या घटना दाखवते, आणि दुसरी ओळ strongSwan सहकाऱ्याकडे सध्या असलेले सुरक्षा संबंध दाखवते. टाइमस्टॅम्पची सूचना दिसलेल्या क्षणाशी तुलना करा; जुळल्यास नेटवर्क नाही, टाइमर सिद्ध होतो.

काय नोंदवायचे आणि काय बंद करू नये

हाताने लॉगिन यशस्वी होत असेल आणि स्वयंचलित पुनर्वापर सातत्याने अपयशी होत असेल, तर ऑपरेटरला तसेच सांगा. ते घटकाचे नाव घेते: पुनर्वापराचा मार्ग, ओळखपत्र नाही. अपयशाची वेळ, वापरले जाणारे खाते आणि तुम्ही पाहिलेल्या सूचनेचा प्रकार समाविष्ट करा.

पुन्हा कनेक्ट शांत करण्यासाठी दुसरा घटक बंद करू नका, प्रमाणपत्र पडताळणी वगळू नका आणि स्क्रिप्टमध्ये ओळखपत्रे पेस्ट करू नका. यापैकी प्रत्येक धोरण लागू करण्यासाठी असलेली तपासणी काढून टाकते, आणि प्रत्येक लॉगिन सूचनेचे घटनेत रूपांतर करते.

त्याऐवजी समर्थित प्रवाह मागा: आव्हान पूर्ण करू शकणारा क्लायंट, कामकाजाच्या दिवसाशी जुळणारे टोकन आयुष्य, किंवा सूचना दाखवू न शकणाऱ्या यंत्रासाठी मंजूर बिगर-परस्परसंवादी प्रोफाइल. हे सर्व असे संरचना निर्णय आहेत जे कोणी मंजूर करू शकते, जे तोडगा नाही.

संबंधित लेख