मोठ्या अपलोडदरम्यान 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

क्लायंटची कालबाह्यता नियोजित की-पुनर्नवीनीकरणाशी किंवा सत्र धोरणाच्या घटनेशीही जुळू शकते. घटनांच्या क्रमासाठी केवळ ॲप्लिकेशनचा त्रुटी संदेश नव्हे, क्लायंटचा स्वतःचा लॉग वाचा.

एक गोष्ट बदला आणि पुन्हा करा

जिथे प्लॅटफॉर्मला आधार आहे तिथे अपलोड दर मर्यादित करा किंवा मोठ्या प्रमाणातील रहदारी परस्परसंवादी रहदारीखाली वर्गीकृत करा, जेणेकरून रांग कधीही भरणार नाही. मग तोच कामाचा भार पुन्हा करा आणि आधीसारखेच तेच तीन आकडे तुलना करा. वेग चाचणी सुधारणारे पण कालबाह्यता तशीच ठेवणारे बदल काहीच दुरुस्त करत नाहीत.

सर्वत्र कालमर्यादा वाढवणे आणि एन्क्रिप्शन कमकुवत करणे या दोन बदलांमुळे लक्षणे नाहीशी होतात, पण कोणती सीमा अपयशी ठरली हे ओळखले जात नाही. यापैकी कोणतीही दुरुस्ती नाही. दोन्ही अपयश अधिक उशिराकडे, जिथे त्याचे कारण सांगणे कठीण आहे तिथे ढकलतात.

नवीन विनंती आणि वापरकर्ता ज्यावर खरोखर अवलंबून आहे त्या पुनर्जोडणी वर्तनाची चाचणी करून समारोप करा. तक्रार निर्माण करणाऱ्या भाराखालील स्थिरता हाच नोंदवण्यायोग्य एकमेव निकाल आहे.