साठ सेकंड का TLS टाइमआउट: कौन-सा सिरा वास्तव में रुका?

क्लाइंट साठ सेकंड बाद कुंजी-बातचीत के बारे में संदेश के साथ हार मान लेता है, और लैपटॉप यह नहीं बताता कि क्यों। वह वाक्य क्लाइंट के धैर्य का वर्णन करता है, सर्वर के व्यवहार का नहीं। तीन बिल्कुल अलग स्थितियाँ इसे पैदा करती हैं: पैकेट कभी सही सेवा तक नहीं पहुँचा, सेवा ने कुछ भी लॉग करने से पहले उसे गिरा दिया, या सेवा ने उसे अस्वीकार किया और यह कहीं बताया जहाँ क्लाइंट देख नहीं सकता। दोनों सिरों पर एक प्रयास का मिलान ही इन्हें अलग करता है।

एक प्रयास को ऐसी पहचान दें जिसे आप खोज सकें

आरंभ समय उसके समय क्षेत्र के साथ लिखें, प्रोफ़ाइल का नाम, वह गंतव्य जिसे क्लाइंट ने वास्तव में हल किया, पोर्ट, और यह कि कनेक्शन UDP है या TCP। यदि प्रोफ़ाइल में कई दूरस्थ प्रविष्टियाँ हैं, तो लिखें कि उस प्रयास ने कौन-सी चुनी, क्योंकि पुनः प्रयास आपके पढ़े जा रहे फ़ाइल को बदले बिना अगली प्रविष्टि पर जा सकता है।

अंतिम बिंदु सक्रिय लॉग से लें, उस डाउनलोड से नहीं जो आपको याद है। निजी पते की ओर इशारा करने वाली प्रोफ़ाइल पूरी तरह वैध है और ऐसे नेटवर्क से पूरी तरह अनुपयोगी है जो वहाँ रूट नहीं कर सकता, और वह स्थिति बंद सर्वर जैसी ही दिखती है।

फिर ऑपरेटर से इच्छित इंस्टेंस पर वही विंडो माँगें। घड़ी का अंतर इतना सामान्य है कि कुछ मिनटों का फ़र्क़ एक मेल खाती घटना को अनुपस्थित दिखा सकता है, इसलिए यह निष्कर्ष निकालने के बजाय कि कोई घटना नहीं थी, फ़र्क़ दर्ज करें।

चार अवलोकन, चार अलग अगले कदम

सर्वर क्या दर्ज करता है, यही शाखा तय करता है। किसी भी प्रयास का अभाव पता-निर्धारण, परिवहन या सेवा तक के मार्ग की ओर इशारा करता है। सामान्य अदला-बदली से पहले गायब होने वाले आने वाले पैकेट वास्तविक सेवा की नियंत्रण-चैनल आवश्यकताओं की ओर इशारा करते हैं। नामित अस्वीकृति उस वस्तु की ओर इशारा करती है जिसका वह नाम लेती है। जो उत्तर सर्वर छोड़ते हैं पर कभी क्लाइंट तक नहीं पहुँचते, वे वापसी मार्ग की ओर इशारा करते हैं।

खाली एप्लिकेशन लॉग दिखने से कमज़ोर साक्ष्य है। लॉगिंग अदला-बदली के एक निश्चित बिंदु से शुरू होती है, और उस बिंदु से पहले गिराए गए पैकेट आपके पढ़े जा रहे फ़ाइल में कोई निशान नहीं छोड़ते। जहाँ अनुमति हो, वहाँ ऑपरेटर सेवा और नेटवर्क के अवलोकनों से देख सकता है कि कुछ पहुँचा भी या नहीं।

अपने नोट्स में चारों परिणाम अलग रखें। लुभावना यह है कि उन्हें “सर्वर जवाब नहीं दे रहा” में मिला दिया जाए, और यही वह वाक्यांश है जो लोगों को सिफ़र बदलने भेजता है जब असली समस्या फ़ायरवॉल नियम हो। जो नोट केवल टाइमआउट शब्द दर्ज करता है, उसने वह भेद फेंक दिया जिसके लिए आपने अभी कीमत चुकाई।

जिस चरण का नाम साक्ष्य लेते हैं, उसे ठीक करें

पूरा हुआ TCP कनेक्शन केवल यह साबित करता है कि किसी चीज़ ने सॉकेट स्वीकार किया। यह साबित नहीं करता कि श्रोता वह OpenVPN सेवा है जिसे आपने कॉन्फ़िगर किया, और उसी होस्टनाम पर एक वेब सर्वर ब्राउज़र को बखूबी जवाब देता है जबकि टनल के लिए वह अप्रासंगिक है।

यदि सर्वर रद्द करने की समय-सीमा बीती सूची की रिपोर्ट करता है, तो वह क्लाइंट के अंतिम टाइमआउट से कहीं अधिक विशिष्ट तथ्य है, और सुधार नेटवर्क का नहीं, प्रमाणपत्र प्राधिकरण का है। यदि दोनों सिरे नियंत्रण-चैनल सुरक्षा या साझा सामग्री पर सहमत नहीं हैं, तो पासवर्ड रीसेट करने से कुछ नहीं बदलता, क्योंकि कोई भी क्रेडेंशियल जाँचे जाने से पहले ही त्याग होता है।

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

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

विंडो बढ़ाने से वास्तव में क्या बदलता है

साठ सेकंड क्लाइंट की हैंडशेक विंडो है, और समुदाय क्लाइंट संदर्भ उस विकल्प का दस्तावेज़ीकरण करता है जो उसे समायोजित करता है। इसे बढ़ाने से क्लाइंट हार मानने से पहले अधिक प्रतीक्षा करता है। यह अनुपस्थित सेवा को प्रकट नहीं करता और अस्वीकृत पैकेट को स्वीकार्य नहीं बनाता।

धीमी कड़ी या भारी भार वाले सर्वर पर लंबी विंडो का वैध उपयोग है, और जब आपके पास साक्ष्य हों कि अदला-बदली धीरे-धीरे आगे बढ़ रही है, बिल्कुल नहीं हो रही ऐसा नहीं, तब इसे आज़माना उचित है। पहले आज़माना केवल उसी निदान को एक और मिनट देर करता है और समयरेखा पढ़ना कठिन बनाता है। यदि समयरेखा ऐसी अदला-बदली दिखाए जो आगे बढ़कर रुक जाए, तो विंडो भार का लक्षण है, पहुँच का नहीं।