साठ सेकंदांचा TLS टाइमआउट: नेमकी कोणती बाजू थांबली?

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

एका प्रयत्नाला अशी ओळख द्या जी तुम्ही शोधू शकता

सुरुवातीची वेळ तिच्या कालविभागासह, प्रोफाइलचे नाव, क्लायंटने प्रत्यक्षात सोडवलेले गंतव्य, पोर्ट, आणि कनेक्शन UDP आहे की TCP हे लिहून ठेवा। प्रोफाइलमध्ये अनेक दूरस्थ नोंदी असल्यास, त्या प्रयत्नाने कोणती निवडली ते नोंदवा, कारण पुन्हा प्रयत्न तुम्ही वाचत असलेली फाइल न बदलता पुढच्या नोंदीकडे गेला असू शकतो।

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

मग ऑपरेटरला इच्छित इन्स्टन्सवर तीच विंडो मागा। घड्याळातील फरक इतका सामान्य आहे की काही मिनिटांचा फरक जुळणाऱ्या घटनेला अनुपस्थित दाखवू शकतो, म्हणून घटना नव्हती असा निष्कर्ष काढण्याऐवजी फरक नोंदवा।

चार निरीक्षणे, चार वेगळी पुढची पावले

सर्व्हर काय नोंदवतो त्यावर शाखा ठरते। कोणत्याही प्रयत्नाचा अभाव पत्ता-निर्धारण, वाहतूक किंवा सेवेकडे जाणाऱ्या मार्गाकडे निर्देश करतो। सामान्य देवाणघेवाणीपूर्वी गायब होणारे येणारे पॅकेट प्रत्यक्ष सेवेच्या नियंत्रण-चॅनेलच्या गरजांकडे निर्देश करतात। नावाने नकार ज्या वस्तूला तो नाव देतो तिकडे निर्देश करतो। संदेश सर्व्हर सोडून कधीच क्लायंटपर्यंत न पोहोचणारी उत्तरे परतीच्या मार्गाकडे निर्देश करतात।

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

तुमच्या नोंदींमध्ये चारही निकाल वेगळे ठेवा। त्यांना “सर्व्हर प्रतिसाद देत नाही” मध्ये विलीन करण्याचा मोह असतो, आणि खरी अडचण फायरवॉल नियम असताना लोकांना सिफर बदलायला पाठवणारे तेच वाक्य असते। फक्त टाइमआउट हा शब्द नोंदवणाऱ्या नोंदीने तुम्ही नुकतीच ज्यासाठी किंमत दिली तो फरक टाकून दिला आहे।

पुरावा ज्या टप्प्याचे नाव घेतो तो दुरुस्त करा

पूर्ण झालेले TCP कनेक्शन फक्त काहीतरी सॉकेट स्वीकारले हे सिद्ध करते। ऐकणारा तुम्ही संरचित केलेली OpenVPN सेवा आहे हे ते सिद्ध करत नाही, आणि त्याच होस्टनावावरचा वेब सर्व्हर ब्राउझरला उत्तम प्रतिसाद देतो पण टनेलशी त्याचा काही संबंध नसतो।

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

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

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

विंडो वाढवल्याने प्रत्यक्षात काय बदलते

साठ सेकंद म्हणजे क्लायंटची हँडशेक विंडो, आणि समुदाय क्लायंट संदर्भ ती समायोजित करणाऱ्या पर्यायाचे दस्तऐवजीकरण करतो। ती वाढवल्याने क्लायंट हार मानण्यापूर्वी जास्त काळ वाट पाहतो। त्याने अनुपस्थित सेवा प्रकट होत नाही आणि नाकारलेले पॅकेट स्वीकारार्ह होत नाही।

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