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.20

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