IPsec माथि ठूला प्याकेट हराउँछन् तर साना ping काम गर्छन्

टाढाका शेलहरू प्रतिक्रियाशील रहन्छन्, साना जाँचहरू जवाफ दिन्छन्, र त्यसपछि फाइल प्रतिलिपि सुस्त रूपमा अगाडि बढ्छ र कसैले देखाउन सक्ने कुनै त्रुटि बिना अड्किन्छ। ठूलो पेलोडसँग ping गर्दा यो तुरुन्तै दोहोरिन्छ, र त्यही स्थानान्तरण स्थानीय नेटवर्कबाट काम गर्छ। इन्क्रिप्शनमा केही पनि सुस्त छैन; केही प्याकेट कहिल्यै पुग्दैनन्। दुई फरक विभाजनले त्यो संकेत बनाउन सक्छन्, र तिनीहरूले फरक प्रमाण छोड्छन्।

प्याकेट विभाजन गर्न सकिने दुई ठाउँ

इन्क्रिप्शन अघि, राउटरले धेरै ठूलो आन्तरिक प्याकेट विभाजन गरेर प्रत्येक टुक्रा छुट्टै सुरक्षित गर्न सक्छ। इन्क्रिप्शन पछि, विभाजन हुने भनेको तयार बाह्य प्याकेट हो, र टाढाको छेउले केही पनि डिक्रिप्ट गर्नु अघि त्यसलाई फेरि जोड्नुपर्छ। एउटै लक्षण, प्राप्तकर्ताका लागि फरक काम र तपाईंका लागि फरक नियन्त्रण।

यो भिन्नता महत्त्वपूर्ण छ किनभने गलत पक्षतर्फ लक्षित सुधारले विफलता नसारी एउटा संख्या मात्र बदल्छ। इन्टरफेसमा अस्वीकार गरिएको प्याकेट कहिल्यै बाह्य प्याकेट बन्दैन, त्यसैले बाह्य पक्षको कुनै सेटिङले त्यसलाई बचाउन सक्दैन।

आकारको निर्णय वास्तवमा कहाँ गरिन्छ

टनेल इन्टरफेसले IP MTU बोक्छ, र त्यो मानले IPsec चरणले देख्नु भन्दा धेरै अघि धेरै ठूलो आन्तरिक प्याकेट अस्वीकार गर्न सक्छ। बाह्य हेडरमा बिट राख्दा त्यो अघिल्लो निर्णय पुनरावलोकन हुँदैन, किनभने प्याकेट पहिले नै अस्वीकार भइसकेको छ। त्यसैले आन्तरिक MTU बढाउँदा कहिलेकाहीँ सुधार्नुको सट्टा बिग्रन्छ। दुवैमध्ये कुनै पनि बदल्नु अघि इन्टरफेसको मान र बाह्य व्यवहार पढ्नुहोस्, किनभने सस्तो परिवर्तन नै सामान्यतया लक्षण व्याख्या गर्ने हो।

पहिले इन्टरफेसको मान जाँच्नुहोस्, त्यसपछि बाह्य व्यवहार। दुई संख्या, दुई चरण, र सामान्यतया तीमध्ये एउटा मात्र जिम्मेवार हुन्छ।

बाह्य बजेट आन्तरिक बजेट होइन

हरेक इन्क्याप्सुलेसनले हेडरमा बाइट खर्च गर्छ, र मात्रा यातायात, ठेगाना परिवार र NAT ट्राभर्सल समावेश छ कि छैन भन्नेमा निर्भर गर्छ। स्थानीय लिङ्कमा अटाउने आन्तरिक प्याकेटले त्यसपछिको बाटोमा नअटाउने बाह्य प्याकेट अझै बनाउन सक्छ। अनुमान गर्नुको सट्टा थप खर्च नाप्नुहोस्, किनभने हरेक वैकल्पिक हेडर बिलमा थपिन्छ। NAT ट्राभर्सल भएको टनेलले नाङ्गो टनेलभन्दा बढी तिर्छ, र त्यो भिन्नता हिजो काम गरेको स्थानान्तरण तोड्न पर्याप्त छ।

जब बाह्य प्याकेटले डु-नट-फ्र्यागमेन्ट बिट बोक्छ, त्यसलाई अगाडि पठाउन नसक्ने होपले त्यसलाई छोड्छ र ICMP सन्देश फर्काउनुपर्छ। यदि त्यो सन्देश कतै फिल्टर भयो भने, पठाउनेले फेरि प्रयास गरिरहन्छ र प्रयोगकर्ताले व्याख्या बिना अड्किएको देख्छ। त्यही मौन छोडाइ आकारको समस्या गतिको समस्या भनेर रिपोर्ट गर्ने सामान्य कारण हो।

IPv6 ले एउटा विकल्प हटाउँछ

IPv6 राउटरहरू ट्रान्जिटमा विभाजन गर्दैनन्, त्यसैले बाह्य प्याकेट या त अटाउँछ या Packet Too Big सन्देशसँग हराउँछ। त्यो सन्देश एकमात्र प्रतिक्रिया माध्यम बन्छ, र त्यसलाई रोक्दा पछिका हरेक ठूलो स्थानान्तरणको लागि बाटो पत्ता लगाउने काम बिग्रन्छ। IPv4 राउटरहरूले बिट स्पष्ट हुँदा ठूलो प्याकेट विभाजन गर्न सक्छन्, जसले अरू केहीले त्यो बिट नराखेसम्म खराबी लुकाउँछ।

मिश्रित स्ट्याकमा एउटै टनेलले दुई परिवारका लागि फरक व्यवहार गर्न सक्छ, त्यसैले IPv4 मा गरिएको एउटा परीक्षणले IPv6 को गुनासो टुंग्याउँदैन। एउटा परिवार मात्र अभ्यास गर्ने जाँचले आधा जवाफ ननापी छोड्छ।

TCP खण्ड नीति सामान्य उत्तर होइन

अधिकतम खण्ड आकार सीमित गर्नाले TCP प्रवाहलाई मद्दत गर्छ, र समस्या तिनीहरूमै सीमित भएको बेला त्यो उचित नियन्त्रण हो। यसको UDP मा कुनै प्रभाव पर्दैन, जसले DNS, केही आवाज प्रोटोकल र वेब ट्राफिकको बढ्दो हिस्सा बोक्छ।

यो लागू गर्नुहोस्, त्यसपछि असफल भएको कार्यभार जाँच्नुहोस्। यदि UDP मामला अझै असफल भयो भने, खण्ड नीति कहिल्यै उत्तर थिएन र इन्टरफेस बजेटलाई अझै ध्यान चाहिन्छ। पहिले असफल कार्यभारको प्रोटोकल पहिचान गर्नुहोस्, त्यसपछि त्यसमा लागू हुने नियन्त्रण छान्नुहोस्।

काम गर्ने क्रम

बाँच्ने सबैभन्दा ठूलो पेलोड लेख्नुहोस्, त्यसपछि इन्टरफेस MTU, त्यसपछि बाह्य प्याकेटले डु-नट-फ्र्यागमेन्ट बिट बोक्छ कि बोक्दैन, र अन्तमा ICMP प्रतिक्रिया पठाउनेसम्म पुग्छ कि पुग्दैन। त्यो क्रमले अनुमान नगरी खराबी साँघुरो बनाउँछ। हरेक अवलोकन समय-छाप र अन्तिम बिन्दुसँग राख्नुहोस्, किनभने बाटो बदलिँदा चारै संख्या सर्छन्।

एउटा मान बदल्नुहोस्, मूल स्थानान्तरण फेरि जाँच्नुहोस् र नतिजा राख्नुहोस्। ठूलो जाँच पास गर्ने तर अनुप्रयोगमा अझै अड्किने टनेल अर्को समस्यामा गएको छ, र त्यो लेख्न लायक प्रगति हो। अर्को व्यक्तिले निष्कर्षभन्दा संख्या रुचाउँछ।