पृष्ठे लोड होतात पण VPN वर अपलोड अडकतात: कोणते कारण जिंकते
आकारावर अवलंबून असलेला अडथळा मार्ग MTU दोषाशी जुळतो, तसेच DNS, ॲप मर्यादा किंवा अस्थिर टनेलशीही जुळतो। चार निरीक्षणे कोणते ते ठरवतात।
पृष्ठे लोड होतात, VPN जोडले गेल्याचे सांगते, आणि फाइल अपलोड दरवेळी त्याच ठिकाणी गोठते। या वर्णनाशी चार स्पष्टीकरणे जुळतात: पॅकेट आकाराची समस्या, नाव-निराकरणाची समस्या, ॲपची मर्यादा आणि सतत रीसेट होणारे टनेल। प्रत्येकाला वेगळ्या निरीक्षणाने सिद्ध किंवा नाकारता येते, म्हणून निर्णय हा कारणाचा अंदाज लावणे नव्हे, तर योग्य चाचणी निवडणे आहे।
चार उमेदवार आणि एक आकार
अपयशाच्या आकारापासून सुरुवात करा, कारण कोणतेही साधन उघडण्यापूर्वी तो यादीचा मोठा भाग काढून टाकतो। स्थिर आकारावर होणारा अडथळा उलटे सिद्ध होईपर्यंत आकाराची समस्या आहे। यादृच्छिक ठिकाणी होणारा अडथळा हानी किंवा स्थिरतेची समस्या आहे। जोडणी उघडण्यापूर्वीचे अपयश हे नावाची समस्या आहे।
चौथा उमेदवार ॲप आहे। अपलोड मर्यादा, विनंत्यांच्या वेळेच्या मर्यादा आणि प्रॉक्सीच्या बॉडी-आकाराच्या वरच्या मर्यादा अशी अपयशे निर्माण करतात जी ब्राउझरमधून नेटवर्क दोषासारखी दिसतात, आणि ती सहसा अडकण्याऐवजी नकार म्हणून येतात।
काहीही चाचणी करण्यापूर्वी दिसलेला आकार लिहून ठेवा। "अगदी त्याच बाइट संख्येवर, दरवेळी, टनेल चालू असताना थांबते" — "अपलोड चालत नाहीत" पेक्षा कितीतरी जास्त मजबूत प्रारंभबिंदू आहे।
मग चाचणीच्या वेळी मार्ग स्थिर ठेवा। एक्झिट, प्रोटोकॉल आणि सर्व्हर एकाच वेळी बदलल्यास असे निकाल मिळतात जे यापैकी कोणालाही देता येत नाहीत। प्रति फेरी एक चल, आणि तो लिहून ठेवा।
धोरणाला स्पर्श करण्यापूर्वी आकार अर्धवट करा
सर्वात स्वस्त भेदक म्हणजे एक संख्या बदलणारी प्रोब। गंतव्यस्थानाकडे वाढत्या आकाराचे, तुकडे टाळणारे पिंग पाठवा, आणि तुम्ही नियंत्रित करता ती फाइल त्याच सेवेवर अपलोड करा, मग प्रत्येक कुठे थांबते याची तुलना करा।
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadपहिली आज्ञा पूर्ण आकाराचे पॅकेट मार्गातून जाते का हे सांगते। 1500 बाइट MTU वर जे ICMP पेलोड विभाजित होत नाही त्याचा कमाल आकार 1472 बाइट आहे, आणि आतील पॅकेट सुरू होण्यापूर्वी टनेल त्या बजेटमधून अधिक घेते। दुसरी ॲप-स्तराच्या हस्तांतरणासाठी आकार आणि कालावधी देते, आणि खरे महत्त्वाचे तेच आहे।
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
दोन्ही एकत्र वाचा। उंबरठ्यावर अपयशी होणाऱ्या प्रोब आणि त्याच उंबरठ्याजवळ थांबणारे अपलोड — ही सुसंगत कथा आहे। सर्व प्रोब यशस्वी होत असताना अपलोड मार्ग स्पष्टपणे वाहून नेईल अशा बाइट संख्येवर अडकत असेल, तर ते ॲप किंवा सर्व्हरकडे निर्देश करते, आणि MTU चे कितीही काम केले तरी ते बदलणार नाही। तो नकारात्मक निकाल सकारात्मकाइतकाच मौल्यवान आहे। तो तपासणीची सर्वात महाग शाखा काढून टाकतो।
मग हस्तांतरणादरम्यान स्थिरता तपासा, कारण मोठ्या अपलोडच्या मध्ये की नूतनीकरण करणारे टनेल असे अपयश निर्माण करते जे आकारावर अवलंबून दिसते पण नसते। अपटाइम वाचन हे ते सिद्ध करण्याचा सर्वात स्वस्त मार्ग आहे।
दुरुस्ती आणि पर्यायी उपाय यातील निवड करा
पुरावे आकाराकडे निर्देश करत असल्यास दोन प्रामाणिक उत्तरे आणि एक अप्रामाणिक उत्तर आहे। प्रामाणिक म्हणजे आवश्यक ICMP प्रतिसादाला परवानगी देऊन मार्ग-MTU शोध पुनर्संचयित करणे, किंवा घोषित सेगमेंट आकार मर्यादित करणे जेणेकरून सहकारी लहान सेगमेंट पाठवतील। अप्रामाणिक म्हणजे फोरममधून नकल केलेल्या मूल्यापर्यंत इंटरफेस MTU कमी करणे आणि ते काय बदलले हे कधीही तपासणे नाही।
निवड तुम्ही काय नियंत्रित करता यावर अवलंबून आहे। तुम्ही चालवता त्या नेटवर्कवर ICMP संदेशांना परवानगी देणे ही स्वच्छ दुरुस्ती आहे, कारण ते प्रत्येक प्रोटोकॉलसाठी यंत्रणा चालू ठेवते। ज्या मार्गावर तुमचे नियंत्रण नाही, तिथे मर्यादित करणे हा व्यवहार्य पर्याय आहे, आणि तो संपूर्ण सर्व्हरवर नव्हे तर अरुंदपणे लागू केला पाहिजे।
पुरावे ॲपकडे निर्देश करत असल्यास ॲप किंवा त्याचे प्रॉक्सी संरचना दुरुस्त करा। 413 प्रतिसाद आणि लटकलेली जोडणी वेगवेगळी अपयशे आहेत, आणि दुसरे सहसा स्वतःच्या मर्यादा असलेल्या प्रॉक्सीसह साखळीत कुठेतरी कालबाह्यता असते।
कोणत्याही प्रकारे, मूळ मूल्ये ठेवा आणि परत केल्यानंतर पुन्हा चाचणी करा। यशस्वी हस्तांतरणाशी जुळणारा बदल हा तोच कारण होता याचा पुरावा नाही, आणि परत करण्याची क्षमता हीच निदानाला योगायोगापासून वेगळे करते।
निर्णय नोंदवा जेणेकरून तो पुढील घटनेपर्यंत टिकेल
चार तथ्ये पुरेशी आहेत: दिसलेला अपयशाचा आकार, प्रोबचे निकाल, तुम्ही केलेला बदल आणि पुनर्चाचणीचा निकाल। त्यांच्यासह पुढील व्यक्ती सांगू शकते की समस्या तीच आहे की त्याच लक्षणांची नवीन।
मार्गाचा संदर्भही नोंदवा, कारण MTU चा निष्कर्ष विशिष्ट दुव्यासाठी असतो। घरी चालणारा आणि हॉटेलमध्ये अपयशी होणारा लॅपटॉप दोन मार्ग ठेवतो, आणि एकावर लागू केलेली दुरुस्ती दुसऱ्याबद्दल काहीही सांगत नाही।
शेवटी, "VPN ने अपलोड तोडले" या सारांशाला विरोध करा। टनेल काम करणाऱ्या आणि अपयशी दोन्ही प्रकरणांत होते; जे बदलले ते म्हणजे मार्गाला वाहून न्यावे लागणाऱ्या पॅकेटचा आकार, किंवा हस्तांतरण जिथे थांबवले गेले ते ठिकाण। खऱ्या यंत्रणेचे नाव देणे हेच टिप्पणी उपयुक्त करते।