बड़े अपलोड के दौरान VPN कट जाता है: पहले कतार पढ़ें

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

हर रन में एक चर बदलें और एंडपॉइंट स्थिर रखें।

दोहराने योग्य भार तुलना बनाएँ

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

ध्यान दें कि कौन-सी घटना पहले दिखती है। किसी भी त्रुटि से पहले बढ़ता राउंड-ट्रिप समय कतार की ओर संकेत करता है; स्थिर विलंबता के साथ कड़ी समय-समाप्ति कुछ और संकेत करती है, जैसे कुंजी बदलना या खाते पर कोई कार्रवाई। दोनों पैटर्न अलग-अलग अगले कदमों की ओर ले जाते हैं। कुछ भी बदलने से पहले अवलोकन लिख लें।

आउटपुट को समय-चिह्नों के साथ सहेजें ताकि भारित और निष्क्रिय रन की पंक्ति-दर-पंक्ति तुलना हो सके।

गति नहीं, कतार पढ़ें

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

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

भारित विलंबता के आँकड़ों की निष्क्रिय आँकड़ों से तुलना करें। पैकेट हानि के बिना दहाई मिलीसेकंड से सैकड़ों तक की छलांग कतार है; स्थिर विलंबता के साथ हानि किसी दूसरी खराबी की ओर इशारा करती है।

डिवाइस और नियंत्रण पथ जाँचें

एन्क्रिप्शन और अग्रेषण प्रोसेसर का समय लेते हैं, और छोटा राउटर या गर्मी से सीमित लैपटॉप व्यस्त रहते समय पैकेट गिरा सकता है। एक प्रक्रिया के प्रतिशत की जगह समग्र भार देखें, क्योंकि कर्नेल अग्रेषण और इंटरप्ट प्रबंधन वहाँ नहीं दिखते जहाँ लोग आमतौर पर देखते हैं।

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

क्लाइंट की समय-समाप्ति निर्धारित कुंजी बदलाव या सत्र नीति की किसी घटना के साथ भी मेल खा सकती है। घटनाओं के क्रम के लिए केवल ऐप्लिकेशन का त्रुटि संदेश नहीं, क्लाइंट का अपना लॉग पढ़ें।

एक चीज़ बदलें और दोहराएँ

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

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

एक नए अनुरोध और उस पुनःकनेक्शन व्यवहार का परीक्षण करके समाप्त करें जिस पर उपयोगकर्ता वास्तव में निर्भर है। जिस भार ने शिकायत पैदा की, उसके तहत स्थिरता ही दर्ज करने योग्य एकमात्र परिणाम है।