VPN द्वारे पाथ MTU शोध: आकार आणि ICMP अंतर

टनेल त्याचे हँडशेक पूर्ण करते, लहान विनंत्या परत येतात, आणि पहिले मोठे हस्तांतरण अडकते। हा नमुना थ्रूपुटकडे इशारा करण्यापूर्वी खूप आधी पाथ MTU कडे इशारा करतो। मार्गावरील प्रत्येक दुवा पॅकेटचा आकार मर्यादित करतो, आणि एन्कॅप्स्युलेशन त्या परवानगीचा काही भाग बाह्य हेडरवर खर्च करते, म्हणून आतील पॅकेट कच्चा मार्ग सुचवतो त्यापेक्षा लहान असणे आवश्यक आहे। बिघाड शांत असतो, आणि म्हणूनच तो निदान करण्यास महाग ठरतो।

पाथ MTU प्रत्यक्षात काय मोजतो

पाथ MTU दोन होस्टमधील मार्गावरील सर्वात लहान दुवा MTU आहे, तुमच्या स्थानिक इंटरफेसवर छापलेला MTU नाही। स्थानिक मूल्य हे अंदाज सुरू होण्याचे ठिकाण आहे, आणि मार्ग तो कुठे संपला पाहिजे हे ठरवतो। म्हणूनच एकच टनेल एका प्रवेश नेटवर्कवर काम करू शकते आणि दुसऱ्यावर अडकू शकते: मार्ग बदलला, कॉन्फिगरेशन नाही। एकदा मोजून सर्वत्र गृहीत धरणे हीच ती चूक आहे जी ही समस्या जिवंत ठेवते।

टनेलसाठी महत्त्वाची संख्या आतील MTU आहे, जी बाह्य मार्गाची परवानगी वजा एन्कॅप्स्युलेशन जे खर्च करते ते आहे। WireGuard बाह्य IP हेडर आणि UDP हेडर जोडते; इतर ट्रान्सपोर्ट स्वतःचे जोडतात। आतील आकार खूप उंच ठेवला तर प्रत्येक पूर्ण-आकार पॅकेटला फ्रॅगमेंटेशन लागेल जे कदाचित कधीही होणार नाही।

टनेल उपयुक्त पॅकेट का लहान करते

टनेल इंटरफेस भौतिक दुव्याचा MTU ठेवत असेल, तर प्रत्येक मोठे पॅकेट खाली कोणी ते फ्रॅगमेंट करायला तयार असेल यावर अवलंबून असते। IPv4 तत्त्वतः त्यास परवानगी देते, पण फ्रॅगमेंट करू नका असे सांगितलेला राउटर त्याऐवजी त्रुटी परत करतो। IPv6 राउटर ट्रान्झिटमध्ये कधीच फ्रॅगमेंट करत नाहीत, म्हणून तेच सेटिंग पत्ता कुटुंबानुसार वेगळे वागते। कोणत्याही प्रकारे, काहीतरी परत कळवेपर्यंत पाठवणारा काहीही शिकत नाही।

व्यावहारिक परिणाम असा आकार आहे जो हँडशेकमध्ये बसतो पण पेलोडमध्ये बसत नाही। TLS ClientHello किंवा DNS क्वेरी छोट्या झालेल्या मार्गातून न छोऊन जाण्याइतकी लहान असते, तर मोठे हस्तांतरण तसे नसते। म्हणून लक्षणे विशिष्ट होस्टभोवती नाही तर विशिष्ट क्रियांभोवती जमतात।

फीडबॅक आल्यावरच शोध कार्य करतो

IPv4 शोध don't-fragment बिटवर अवलंबून आहे: जो राउटर पॅकेट पुढे पाठवू शकत नाही तो पुढील हॉपच्या MTU सह ICMP fragmentation-needed परत करतो, आणि पाठवणारा आपला अंदाज कमी करतो। IPv6 त्याऐवजी Packet Too Big संदेश वापरते, कारण राउटर ट्रान्झिटमध्ये फ्रॅगमेंट करत नाहीत। दोन्ही यंत्रणा गृहीत धरतात की संदेशाला पाठवणाऱ्याकडे परत जाण्याचा मार्ग सापडेल, टनेलमधून आणि परतीच्या मार्गावरील कोणत्याही फायरवॉलच्या पलीकडे। ते गृहीतक फसल्यास, पाठवणारा मार्ग वाहू शकत नाही असा आकार पुन्हा पुन्हा प्रयत्न करत राहतो।

echo request आणि echo reply ला परवानगी देणाऱ्या फायरवॉलने त्या त्रुटी प्रकारांना परवानगी दिलीच असे नाही। ICMP एक कुटुंब आहे, आणि येथे महत्त्वाचे सदस्य त्रुटी आहेत, इको जोडी नाही। टनेलच्या दोन्ही टोकांवर आणि त्यांच्यातील मार्गावर नियंत्रण-ट्रॅफिक धोरण तपासा, आणि सर्वत्र प्रत्येक ICMP प्रकारास परवानगी देण्याऐवजी प्लॅटफॉर्मच्या समर्थित मार्गदर्शनाचे पालन करा।

तीच फिल्टरिंग टनेलच्या आतही असू शकते। आतील मार्ग त्रुटी टाकून देतो पण बाह्य मार्ग ती वाहतो, तर पाठवणारा एन्कॅप्स्युलेटेड ट्रॅफिक कधीच प्रत्यक्षात न पाहणाऱ्या मर्यादेशी जुळवून घेऊ शकतो।

संख्या अंदाजण्याऐवजी मार्ग तपासा

गंतव्य, प्रवेश नेटवर्क आणि टनेल स्थिर ठेवा, नंतर फक्त पॅकेटचा आकार बदला। MTU संकेतासह अयशस्वी होणारी don't-fragment चाचणी तुम्हाला पुढील हॉपची मर्यादा देते; एखादा आकार पास होईपर्यंत पुनरावृत्ती करा, आणि आकार व पत्ता कुटुंब दोन्ही नोंदवा।

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

बसणारा पिंग हे सिद्ध करत नाही की खऱ्या अनुप्रयोगाचे पूर्ण-आकार विभाग बसतील, म्हणून प्रत्यक्षात अयशस्वी झालेल्या हस्तांतरणासह चाचणीची पुनरावृत्ती करा। सर्वात मोठ्या कार्यरत चाचणीची तुम्ही कॉन्फिगर केलेल्या टनेल MTU शी तुलना करा, आणि दोन्ही संख्या तुमच्या नोट्समध्ये वेगळ्या ठेवा। त्या अंदाजे एका हेडरएवढ्या वेगळ्या असतील, तर तुम्हाला बिघाड नव्हे तर एन्कॅप्स्युलेशन ओव्हरहेड सापडला आहे।

RFC 4821 मध्ये वर्णन केलेले PLPMTUD वरच्या दिशेने चाचणी करते आणि पोहोचवलेल्या त्रुटींवर विश्वास ठेवण्याऐवजी ट्रान्सपोर्ट पोचपावत्या वापरते। ICMP फिल्टर करणाऱ्या मार्गांवर ते मदत करते, पण समर्थन स्टॅक आणि अनुप्रयोगानुसार बदलते। TCP प्रवाह स्वतः सावरू शकतो तर निश्चित डेटाग्राम आकाराचे UDP अनुप्रयोग अयशस्वी होत राहते।

मूल्य निवडा आणि कारण नोंदवा

टनेल MTU कमी करणे हे निदान आणि वैध दुरुस्ती दोन्ही आहे एकदा तुम्हाला मार्ग माहीत झाल्यावर। कोणता मार्ग आणि कोणती फीडबॅक यंत्रणा गुंतली होती हे जाणण्याचा तो पर्याय नाही, कारण मोबाइल दुव्यासाठी ट्यून केलेले मूल्य फायबर जोडणीवर अनावश्यकपणे लहान असेल। निवडलेला आकार, त्याला न्याय देणारी चाचणी आणि रोलबॅक पायरी नोंदवा।

IPv4 यंत्रणेचे वर्णन RFC 1191 मध्ये आणि IPv6 पॅकेटायझेशन मार्गदर्शन RFC 8201 मध्ये आहे; दोन्हीचा उल्लेख केल्यास पुढील अभियंत्याला गृहीतक पुन्हा काढावे लागत नाही। तुम्ही निवडलेल्या आकारावर हस्तांतरण अजूनही अडकत असेल, तर संख्या कमी करणे थांबवा आणि पुढील स्तर पाहा। प्रत्येक आकारावर अयशस्वी होणारा मार्ग MTU समस्या नाही।