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

अंतराल को संख्या में बदलें

पाँच या छह घटनाएँ एकत्र करें और उनके बीच का अंतर गिनें, दिन की शुरुआत से नहीं। 09:12, 10:12 और 11:12 पर डिस्कनेक्ट होना घंटे की सीमा है; 09:12, 09:27 और 09:42 पर डिस्कनेक्ट होना अंतिम सफल कनेक्शन से पंद्रह मिनट है। परिणाम को निकटतम मिनट में नहीं, सबसे संभावित टाइमर में गोल करें।

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

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

एक जैसे दिखने वाले चार टाइमर

लगभग हर दोहराया जाने वाला टनल पतन इनमें से एक से आता है: प्रोटोकॉल कुंजी-नवीनता, निष्क्रिय मैपिंग की समाप्ति, DHCP या इंटरफ़ेस घटना, या खाता नीति। ये इस बात में भिन्न हैं कि ट्रैफ़िक बह रहा था या नहीं और सीमा पर लॉग क्या कहता है।

नीचे दिए गए हस्ताक्षर सीखने योग्य हैं, क्योंकि वे एक ही लॉग पंक्ति से तीन स्पष्टीकरण खारिज करने देते हैं:

TimerTypical triggerWhat the log shows at the boundary
Protocol rekeyTraffic present, fixed intervalNegotiation lines, sometimes a failure
NAT or firewall idleNo traffic for minutesSilence, then a timeout on send
DHCP lease or link changeHalf the lease, or a radio eventAddress or interface churn
Account session limitWall-clock hours since loginClean disconnect, server-side reason

पहली पंक्ति एक सुरक्षा तंत्र है जो अपना काम कर रहा है, और दूसरी एक मध्यवर्ती उपकरण है जो स्थिति भूल जाता है। इन्हें मिलाने से या तो कुंजी-नवीनता कमजोर पड़ती है या ऐसे फ़ायरवॉल नियम के पीछे भागना पड़ता है जो कभी शामिल ही नहीं था।

व्यस्त बनाम निष्क्रिय बताता है कौन-सा आधा

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

यदि वह निरंतर ट्रैफ़िक सह लेता है, तो कारण कुंजी-नवीनता, लीज़ या नीति का है। यह एक परीक्षण लगभग एक घंटे के अवलोकन में आधे उम्मीदवार हटा देता है, और इसकी कीमत केवल ध्यान है।

परीक्षण के दौरान एक्सेस नेटवर्क अपरिवर्तित रखें। तुलना के बीच में Wi-Fi और Ethernet के बीच बदलना ठीक उसी इंटरफ़ेस घटना को लाता है जिसे आप टाइमर से अलग पहचानना चाहते हैं।

लॉग पंक्ति को सीमा से मिलाएँ

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

ये कमांड प्रत्येक स्रोत से प्रासंगिक विंडो निकालते हैं:

grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg show

यदि तीनों स्रोत टाइमस्टैम्प पर सहमत हैं, तो आप टाइमर के मालिक को जानते हैं। यदि केवल क्लाइंट लॉग में कुछ है, तो संभवतः सर्वर सत्र समाप्त करने वाला नहीं है।

चरण ठीक करें, आइकन नहीं

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

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

संबंधित लेख