दुई सेकेन्ड टिकेर आफैँ सुधारिने जम्ने समस्याले सुरुङले फेरि वार्ता गरेको हो वा रेडियो लड्खडाएको हो भन्ने नहेरी एउटै देखिन्छ। केही पनि नखसेको हुन सक्छ, र यो सम्भावना पहिले जाँच्न लायक छ। छोटो हानिको फट्को, फेरि वार्ता र अनुप्रयोगको रोकावटले किबोर्डमा टाइप गर्ने व्यक्तिलाई उस्तै महसुस गराउँछ। तीनमध्ये एउटा मात्र सुरुङको कन्फिगरेसन बदलेर सुधारिन्छ।

दुई अभिलेख, एक होइन

तलको जडानलाई के भयो र सुरुङले आफैँ के गर्‍यो छुट्टाछुट्टै लेख्नुहोस्। त्यसपछि अनुप्रयोगको रोकावटलाई दुवै अभिलेखसामु राख्नुहोस्। यी कहिलेकाहीँ मिल्ने स्वतन्त्र घटनाक्रम हुन्, र तीनवटैलाई विच्छेद भन्नु सुरुमै उत्तर मान्नु हो।

मिनेटमा एक पटक जाँच्ने मनिटरले दुई सेकेन्डको अवरोध देख्न सक्दैन। त्यो दिनलाई स्वस्थ भनी रिपोर्ट गर्नु प्राविधिक रूपमा सही र व्यवहारमा बेकार हो। तपाईंले उद्धृत गर्ने प्रत्येक नतिजाको छेउमा नमुना अन्तराल लेख्नुहोस्।

अनुप्रयोग जम्दा पहुँच लिङ्कले के गर्‍यो

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

पहिले मार्गहरू पुष्टि गर्नुहोस्, किनकि सार्वजनिक लक्ष्य आफैँ सुरुङबाट मार्गिन सक्छ र त्यसपछि पहुँच मार्गको सट्टा सुरुङ नाप्छ। अवरोधलाई साँच्चै मिति दिने प्रमाण एक तह तल छन्: राउटरमा लिङ्क घटना, मोडेममा पुनःसमकालिक अभिलेख, र बदलिएको 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 observedTunnel log at that secondWhere to look next
two-second pause, plain path answers throughoutnothingthe monitor's resolution, then a loss burst
pause plus a router link event, plain path stops and returnsno restart linethe access link, not the tunnel timer
pause, then a new session identifierrestart linethe restart threshold and what triggered it
one application freezes while both paths answernothingthat application and its server-side work

प्रत्येक पङ्क्ति सुराग हो, फैसला होइन: अन्त्य बिन्दुहरूले ICMP को प्राथमिकता घटाउँछन्, र दुई गन्तव्यले एउटै मार्ग साझा गर्छन् भन्ने छैन। तुलना सम्भव होस् भनेर क्लाइन्ट, गेटवे र अनुप्रयोगका घडी मिलाएर राख्नुहोस्। दुई स्तम्भमा अट्ने पङ्क्तिलाई अर्को अवलोकन चाहिन्छ, निर्णय होइन।

समीक्षा टिक्ने प्रतिवेदनले चार कुराको उत्तर दिन्छ: जम्ने समस्या कति बेर रह्यो, कुन मार्गले जवाफ दिइरहे, त्यो सेकेन्डमा सुरुङले के अभिलेख गर्‍यो, र मनिटरले कति पटक नमुना लिन्छ। ती चार तथ्यले अर्को पाठकलाई सारांशमा भर पर्नुको सट्टा अवलोकन दोहोर्‍याउन दिन्छ। अपटाइम प्रतिशतले तपाईंलाई महत्त्वपूर्ण अन्तराल नै लुकाउँछ, र "VPN खस्यो" भन्ने वाक्यांशले पनि।

सम्बन्धित लेखहरू