MTU कालो प्वाल: साना अनुरोध किन काम गर्छन् तर अपलोड अड्किन्छन्
साना अनुरोध पूरा हुन्छन् जबकि ठूलो अपलोड सधैंका लागि झुन्डिन्छ, र पठाउनेले बाटो साँघुरो छ भन्ने कहिल्यै थाहा पाउँदैन। जहाँ यो टुट्छ त्यो ठ्याक्कै आकार नाप्नुहोस्।
एउटा पृष्ठ लोड हुन्छ, सानो API कल फर्कन्छ, र त्यसपछि फाइल अपलोड क्लाइन्ट हार नमानेसम्म झुन्डिन्छ। सर्भर लगमा यो व्याख्या गर्ने केही छैन, किनकि प्याकेटहरू बाटोको बीचमा उपयोगी जवाफ नपठाई फालिएका थिए। त्यही ढाँचा MTU कालो प्वाल हो: पठाउनेले अनुमान गरेभन्दा साँघुरो लिङ्क, साथै त्यो भन्नबाट चुपचाप इन्कार। असफल हुने आकार दोहोरिने खालको छ, र त्यही कारणले यो निदानयोग्य हुन्छ।
प्वाललाई कालो के बनाउँछ
हरेक लिङ्कमा अधिकतम प्रसारण इकाइ हुन्छ, र अर्को हपको सीमाभन्दा ठूलो प्याकेटलाई या त खण्डन गर्नुपर्छ या त्यो भन्ने ICMP सन्देशसँग अस्वीकार गर्नुपर्छ। बाटोको MTU पत्ता लगाउने काम त्यो सन्देश आउनु र त्यसको सम्मान हुनमा निर्भर छ। यसलाई फिल्टर गर्ने वा बेवास्ता गर्नेले पठाउनेलाई कहिल्यै नअटाउने प्याकेट दोहोर्याइरहन दिन्छ।
इन्क्याप्सुलेसनले यसलाई VPN वरपर सामान्य बनाउँछ, किनकि सुरुङले भौतिक लिङ्कका लागि पहिले नै नापिएको प्याकेटमा बाहिरी हेडर थप्छ। भित्री प्याकेट 1500 बाइटमा वैध छ र इन्क्याप्सुलेट भएको छैन, त्यसैले यो सीमामा मर्छ जबकि साना प्याकेट पार हुन्छन्। पूरा भएको ह्यान्डसेक र चल्ने लगइन पृष्ठले साना प्याकेट चल्छन् भन्ने मात्र प्रमाणित गर्छन्। एप्लिकेसनले पठाउन खोज्ने सबैभन्दा ठूलो प्याकेट नै महत्त्वपूर्ण हुन्छ।
जहाँ यो टुट्छ त्यो आकार पत्ता लगाउनुहोस्
नखण्डन परीक्षणसँग पेलोडको आकार द्विआधारी खोजी गर्नुहोस्, सुरुङको एक छेउको होस्टबाट अर्को छेउको होस्टसम्म। जो सबैभन्दा ठूलो पेलोड पार हुन्छ त्यो तपाईंको प्रयोगयोग्य बाटो MTU बाट हेडरको ओभरहेड घटाएको हो।
ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.201472 बाइटको पेलोड सफा 1500 बाइटको Ethernet बाटोमा सफल हुन्छ, जब IPv4 र ICMP हेडरका 28 बाइट थपिन्छन्। जब त्यही परीक्षण सुरुङ उठेपछि सानो पेलोडमा मात्र सफल हुन्छ, फरक इन्क्याप्सुलेसन ओभरहेड हो, र सुरुङको सीमा नै त्यो ठाउँ हो जहाँ अस्वीकृति सन्देश उत्पन्न हुनुपर्ने थियो। जडान अघि र पछि दुवै संख्या टिप्नुहोस्, किनकि त्यही जोडी प्रमाण हो। एप्लिकेसनले IPv6 प्रयोग गर्दा त्यसका लागि परीक्षण दोहोर्याउनुहोस्, किनकि हेडर ठूलो छ र असफलताको सीमा सर्छ।
सुरुङलाई दोष दिनुअघि प्रमाण पढ्नुहोस्
टाढाका एप्लिकेसनका त्रुटि, भीड र सामान्य हानिले पनि अपलोड अड्काउँछन्, त्यसैले एउटा असफल स्थानान्तरणले कालो प्वाल पहिचान गर्दैन। तिनलाई छुट्याउने आकारको सम्बन्ध हो: 1200 बाइटमा दोहोरिने सफलता र 1400 बाइटमा दोहोरिने अड्काव, उही दिशामा, उही अन्तिम बिन्दुबाट।
दुवै छेउको क्याप्चरले ठूला प्याकेट बाहिर गएर कहिल्यै नआएको, बीचमा कुनै अस्वीकृति नभएको देखाउँछ। सर्भरको सट्टा सीमा उपकरणतिर हेर्ने ठ्याक्कै त्यही क्षण हो, किनकि सर्भरले आफूलाई वास्तवमा आउने हरेक अनुरोधको जवाफ दिइरहेको हुन्छ। भीडले पनि अड्काउँछ, तर त्यो फरक समयमा फरक आकार अड्काउँछ, र त्यो फरक हस्ताक्षर हो।
दुवै यातायातमा मर्मत जाँच्नुहोस्
समर्थित मर्मत भनेको सीमालाई साँचो सीमा जानकारी गराउन दिनु, वा त्यहाँ TCP को अधिकतम खण्ड आकार कसेर राख्नु हो, ताकि कुनै पनि ठूलो खण्ड प्रयास नहोस्। सञ्जालमा हरेक MTU घटाउनु, वा फायरवाल बन्द गर्नु, लक्षण लुकाउँछ र पछि कसैले पनि तर्क गर्न नसक्ने कन्फिगरेसन छोड्छ।
ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20त्यही आकार परीक्षणले प्रमाणित गर्नुहोस्, त्यसपछि असफल भएको एप्लिकेसनले, र दोस्रो प्रोटोकल जाँच्नुहोस्, किनकि UDP एप्लिकेसनले TCP को खण्ड-आकार सुधार कहिल्यै पाउँदैनन्। टिकटमा मूल मानहरू राख्नुहोस्, किनकि उल्टाउन नसकिने मर्मत हुन बाँकी दोस्रो समस्या हो। आकार परीक्षण पास भए पनि अपलोड अड्किरहेको छ भने, कालो प्वाल कारण थिएन, र परिवर्तन फैलाउने होइन, अनुसन्धान अगाडि बढाउनुपर्छ।