दो सेकंड की जमावट: गड़बड़ी VPN की थी या Wi-Fi की?
दो सेकंड का ठहराव और नया VPN सत्र अलग-अलग घटनाएँ हैं। टाइमर बदलने से पहले अभिगम पथ और सुरंग को अलग-अलग समय-रेखाओं पर रखें।
दो सेकंड की जमावट जो अपने आप ठीक हो जाती है, एक जैसी दिखती है, चाहे सुरंग ने फिर से बातचीत की हो या रेडियो लड़खड़ाया हो। यह भी संभव है कि कुछ भी गिरा ही न हो, और उस संभावना को पहले जाँचना चाहिए। हानि का छोटा फटना, फिर से बातचीत और किसी अनुप्रयोग का ठहराव—कीबोर्ड पर टाइप करने वाले व्यक्ति को सब एक जैसे लगते हैं। तीनों में से केवल एक स्थिति सुरंग का विन्यास बदलकर ठीक होती है।
दो अभिलेख, एक नहीं
नीचे के कनेक्शन के साथ क्या हुआ और सुरंग ने स्वयं क्या किया, इसे अलग-अलग लिखें। फिर अनुप्रयोग के विराम को दोनों अभिलेखों के सामने रखें। ये स्वतंत्र घटनाक्रम हैं जो कभी-कभी एक साथ पड़ते हैं, और तीनों को डिस्कनेक्शन कहना शुरू में ही उत्तर मान लेना है।
मिनट में एक बार जाँचने वाला मॉनिटर दो सेकंड का व्यवधान नहीं देख सकता। उस दिन को स्वस्थ बताना तकनीकी रूप से सही और व्यवहार में बेकार है। आप जो भी परिणाम उद्धृत करें, उसके बगल में नमूनाकरण अंतराल लिखें।
अनुप्रयोग के जमे रहते अभिगम लिंक ने क्या किया
नमूनाकरण अंतराल और समय-सीमा तय करते हैं कि मॉनिटर कभी क्या देख सकता था, इसलिए दोनों को परिणाम के बगल में दर्ज करें। जब उपकरण हर साठ सेकंड में नमूना लेता है, तब व्यवधानों की दर्ज अनुपस्थिति का अर्थ बहुत कम है। फिर समय-मुद्राओं के साथ तीन स्थान जाँचें: स्थानीय राउटर, सादे पथ से पहुँचा जाने वाला स्वीकृत बाहरी होस्ट, और सुरंग के पीछे का संसाधन।
पहले मार्गों की पुष्टि करें, क्योंकि कोई सार्वजनिक लक्ष्य स्वयं सुरंग से होकर जा सकता है और तब वह अभिगम पथ की जगह सुरंग को मापता है। जो साक्ष्य वास्तव में व्यवधान की तिथि तय करते हैं वे एक स्तर नीचे हैं: राउटर पर लिंक घटनाएँ, मॉडेम पर पुनःसमन्वयन अभिलेख, और बदला हुआ WAN पता। संचयी त्रुटि काउंटर बताता है कि कुछ गड़बड़ हुआ, कभी नहीं बताता कि कब। उन अभिलेखों को अलग-अलग पढ़ने के बजाय घटना की खिड़की से सहसंबद्ध करें।
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address showकल बढ़ा काउंटर आज सुबह की जमावट के बारे में कुछ नहीं समझाता। सहसंबंध को उसी खिड़की तक सीमित करें जिसकी उपयोगकर्ता ने सूचना दी।
पुनःआरंभ अभिलेख खोजें
खोया हुआ UDP डेटाग्राम अपने आप Community OpenVPN को नई TLS बातचीत शुरू करने पर नहीं लगाता। पुनःआरंभ व्यवहार ping-restart का पालन करता है, और लागू मान सर्वर ने भेजा हो सकता है; 2.6 पुस्तिका उन टाइमरों को परिभाषित करती है। डिलीवरी एक क्षण के लिए टूटती है, देहरी कभी पार नहीं होती, और लॉग खाली रहता है। इसलिए विराम के आसपास लॉग में पुनःआरंभ पंक्ति, नया कनेक्शन या बदला हुआ सत्र पहचानकर्ता खोजें। यदि तीनों में से कोई न दिखे, तो सुरंग ने शायद कुछ नहीं किया और टाइमर कभी समस्या नहीं था।
हर कीपअलाइव को घटाना पहचान को तेज़ दिखाता है और उस रेखा को खिसकाता है जहाँ छोटी हिचकी पुनःकनेक्शन बन जाती है। हर पुनःकनेक्शन में एक प्रमाणीकरण चक्र और मार्गों की पुनःस्थापना लगती है। टाइमर बढ़ाना मृत पथ के अधिक समय तक जीवित दिखने वाली लंबी खिड़की के अलावा कुछ नहीं देता। दोनों कीमत वाले ट्यूनिंग निर्णय हैं, मुफ़्त सुधार नहीं।
अनुपस्थित घटना भी साक्ष्य है, और लोग ठीक इसी तरह की छोड़ देते हैं क्योंकि लॉग में कोई चीज़ उस ओर ध्यान नहीं खींचती। आपने जो खोज की उसे दर्ज करें, केवल उसका परिणाम नहीं।
क्या ठीक करना है यह तुलना तय करे
जब दोनों अभिलेख साथ-साथ हों, तो आवंटन प्रायः स्वयं लिखा जाता है। दोनों पथों पर राउटर लिंक घटना का अर्थ है कि विषय अभिगम कनेक्शन है। शांत सुरंग और उपयोगी सादा पथ का अर्थ है कि विषय बातचीत है।
| What you observed | Tunnel log at that second | Where to look next |
|---|---|---|
| two-second pause, plain path answers throughout | nothing | the monitor's resolution, then a loss burst |
| pause plus a router link event, plain path stops and returns | no restart line | the access link, not the tunnel timer |
| pause, then a new session identifier | restart line | the restart threshold and what triggered it |
| one application freezes while both paths answer | nothing | that application and its server-side work |
हर पंक्ति सुराग है, फ़ैसला नहीं: अंतिम बिंदु ICMP को कम प्राथमिकता देते हैं, और दो गंतव्य ज़रूरी नहीं कि एक ही पथ साझा करें। तुलना संभव हो इसके लिए क्लाइंट, गेटवे और अनुप्रयोग की घड़ियाँ मिलाकर रखें। जो पंक्ति दो स्तंभों में बैठती है उसे एक और प्रेक्षण चाहिए, निर्णय नहीं।
समीक्षा में टिकने वाली रिपोर्ट चार बातों का उत्तर देती है: जमावट कितनी देर रही, कौन-से पथ उत्तर देते रहे, उस सेकंड सुरंग ने क्या दर्ज किया, और मॉनिटर कितनी बार नमूना लेता है। ये चार तथ्य अगले पाठक को सारांश पर भरोसा करने के बजाय प्रेक्षण दोहराने देते हैं। अपटाइम प्रतिशत ठीक उसी अंतराल को छिपाता है जो आपके लिए मायने रखता है, और "VPN गिर गया" वाक्य भी।