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 ची खंड-आकार दुरुस्ती कधीच मिळत नाही। तिकिटात मूळ मूल्ये ठेवा, कारण उलट करता येणार नाही अशी दुरुस्ती होण्याच्या प्रतीक्षेत असलेली दुसरी समस्या आहे। आकार चाचणी उत्तीर्ण झाली तरी अपलोड अडकत असेल, तर काळे भोक कारण नव्हते, आणि बदल वाढवण्याऐवजी तपास पुढे न्यायला हवा।