पेज लोड होते हैं पर 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 ने अपलोड तोड़ दिए" जैसे सारांश का विरोध करें। टनल काम करने और विफल होने दोनों ही स्थितियों में मौजूद थी; जो बदला वह पथ को ढोने वाले पैकेट का आकार था, या वह जगह जहाँ स्थानांतरण रोका गया। वास्तविक तंत्र का नाम देना ही नोट को उपयोगी बनाता है।