IPsec वर मोठे पॅकेट गायब होतात तर लहान ping काम करतात

दूरचे शेल प्रतिसाद देत राहतात, लहान चाचण्या उत्तर देतात, आणि मग फाइल प्रत हळूहळू सरकते आणि कोणालाही दाखवता येईल अशा त्रुटीशिवाय थांबते. मोठ्या पेलोडसह ping हे लगेच पुनरुत्पादित करते, आणि तेच हस्तांतरण स्थानिक नेटवर्कवरून काम करते. एन्क्रिप्शनमध्ये काहीही संथ नाही; काही पॅकेट कधीही पोहोचत नाहीत. दोन वेगवेगळे विभाजन हे लक्षण निर्माण करू शकतात, आणि ते वेगळे पुरावे सोडतात.

पॅकेट विभागता येऊ शकते अशी दोन ठिकाणे

एन्क्रिप्शनपूर्वी, राउटर खूप मोठे अंतर्गत पॅकेट विभागू शकतो आणि प्रत्येक तुकडा स्वतंत्रपणे संरक्षित करू शकतो. एन्क्रिप्शननंतर, विभागले जाते ते पूर्ण झालेले बाह्य पॅकेट, आणि दूरच्या टोकाला काहीही डिक्रिप्ट करण्यापूर्वी ते पुन्हा जोडावे लागते. तेच लक्षण, प्राप्तकर्त्यासाठी वेगळे काम आणि तुमच्यासाठी वेगळे नियंत्रण.

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

आकाराचा निर्णय प्रत्यक्षात कुठे घेतला जातो

टनेल इंटरफेस IP MTU धारण करतो, आणि ते मूल्य IPsec टप्पा ते पाहण्याच्या खूप आधी खूप मोठे अंतर्गत पॅकेट नाकारू शकते. बाह्य हेडरवर बिट लावल्याने तो पूर्वीचा निर्णय पुन्हा तपासला जात नाही, कारण पॅकेट आधीच नाकारले गेले आहे. म्हणूनच अंतर्गत MTU वाढवल्याने कधीकधी सुधारण्याऐवजी बिघडते. दोन्हींपैकी कोणतेही बदलण्यापूर्वी इंटरफेसचे मूल्य आणि बाह्य वर्तन वाचा, कारण स्वस्त बदल हाच सहसा लक्षण स्पष्ट करतो.

प्रथम इंटरफेसचे मूल्य तपासा, नंतर बाह्य वर्तन. दोन संख्या, दोन टप्पे, आणि सहसा त्यापैकी एकच जबाबदार असतो.

बाह्य बजेट अंतर्गत बजेट नाही

प्रत्येक एन्कॅप्स्युलेशन हेडरवर बाइट खर्च करते, आणि प्रमाण वाहतूक, पत्ता कुटुंब आणि NAT ट्रॅव्हर्सल समाविष्ट आहे का यावर अवलंबून असते. स्थानिक दुव्यात बसणारे अंतर्गत पॅकेट त्यापुढील मार्गात न बसणारे बाह्य पॅकेट तयार करू शकते. गृहीत धरण्याऐवजी अतिरिक्त खर्च मोजा, कारण प्रत्येक ऐच्छिक हेडर बिलात जोडले जाते. NAT ट्रॅव्हर्सल असलेली टनेल नग्न टनेलपेक्षा जास्त भरते, आणि फरक काल काम करणारे हस्तांतरण तोडण्यासाठी पुरेसा आहे.

बाह्य पॅकेट डू-नॉट-फ्रॅगमेंट बिट धारण करत असताना, ते पुढे पाठवू न शकणारा हॉप ते टाकून देतो आणि ICMP संदेश परत द्यायला हवा. तो संदेश कुठेतरी फिल्टर झाला तर पाठवणारा पुन्हा प्रयत्न करत राहतो आणि वापरकर्त्याला स्पष्टीकरणाशिवाय थांबा दिसतो. तोच शांत टाकून देणे हे आकाराची समस्या वेगाची समस्या म्हणून नोंदवण्याचे नेहमीचे कारण आहे.

IPv6 पर्यायांपैकी एक काढून टाकतो

IPv6 राउटर मार्गात विभागणी करत नाहीत, म्हणून बाह्य पॅकेट एकतर बसते किंवा Packet Too Big संदेशासह अदृश्य होते. तो संदेश एकमेव अभिप्राय मार्ग बनतो, आणि तो अडवल्याने पुढील प्रत्येक मोठ्या हस्तांतरणासाठी मार्ग-शोध तुटतो. IPv4 राउटर बिट स्पष्ट असताना मोठे पॅकेट विभागू शकतात, जे दुसरे काही तो बिट लावेपर्यंत बिघाड लपवते.

मिश्र स्टॅकवर तीच टनेल दोन कुटुंबांसाठी वेगळे वागू शकते, म्हणून IPv4 वरची एक चाचणी IPv6 तक्रार निकाली काढत नाही. फक्त एका कुटुंबाचा सराव करणारी तपासणी अर्धे उत्तर न मोजता सोडते.

TCP विभाग धोरण सामान्य उत्तर नाही

कमाल विभाग आकार मर्यादित करणे TCP प्रवाहांना मदत करते, आणि समस्या त्यांच्यापुरती मर्यादित असल्यास ते योग्य नियंत्रण आहे. त्याचा UDP वर काहीच परिणाम होत नाही, तर DNS, काही आवाज प्रोटोकॉल आणि वाढता वेब रहदारीचा वाटा UDP वाहतो.

ते लागू करा, नंतर अयशस्वी झालेले काम तपासा. UDP प्रकरण अजूनही अयशस्वी झाल्यास विभाग धोरण कधीच उत्तर नव्हते आणि इंटरफेस बजेटला अजूनही लक्ष देणे आवश्यक आहे. प्रथम अयशस्वी कामाचा प्रोटोकॉल ओळखा, नंतर त्याला लागू असलेले नियंत्रण निवडा.

कामाचा क्रम

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

एक मूल्य बदला, मूळ हस्तांतरण पुन्हा तपासा आणि निकाल ठेवा. मोठी चाचणी उत्तीर्ण होते पण अनुप्रयोगावर अजूनही थांबणारी टनेल दुसऱ्या समस्येकडे गेली आहे, आणि ती लिहून ठेवण्यासारखी प्रगती आहे. पुढच्या व्यक्तीला निष्कर्षापेक्षा संख्या हव्या असतात.