पृष्ठहरू लोड हुन्छन् तर 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 ले अपलोड तोड्यो" भन्ने सारांशको विरोध गर्नुहोस्। टनेल काम गर्ने र असफल दुवै अवस्थामा उपस्थित थियो; बदलिएको कुरा मार्गले बोक्नुपर्ने प्याकेटको आकार, वा स्थानान्तरण रोकिएको ठाउँ थियो। वास्तविक कार्यविधिको नाम दिनु नै टिप्पणीलाई उपयोगी बनाउँछ।