MTU कि MSS? VPN को परिवर्तनले वास्तवमा के सुधार्छ

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

दुई संख्या, दुई वस्तु

MTU लिङ्क वा इन्टरफेसको हो: यो नबाँडी अगाडि बढाउन सकिने सबैभन्दा ठूलो प्याकेट हो। MSS TCP को हो: यो एउटा खण्डले बोक्न सक्ने सबैभन्दा ठूलो TCP पेलोड हो, र यसले TCP र IP दुवै हेडर बाहिर राख्छ। IPv4 भएको सामान्य इथरनेट लिङ्कमा 1500 बाइटको MTU ले परिचित 1460 बाइटको MSS दिन्छ। यी संख्याले फरक तह वर्णन गर्छन् र फरक संयन्त्रबाट आदानप्रदान हुन्छन्। दुवै बाइटमा मापन हुने र दुवै 1500 नजिक हुने भएकाले तिनीहरूलाई भ्रमित गर्न सजिलो छ।

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

बाहिरी अतिरिक्त भार कहाँ पर्छ

VPN ले भित्री प्याकेटलाई अर्कोभित्र राख्छ, र बाहिरी प्याकेट भौतिक मार्गमा अट्नुपर्छ। इन्क्याप्सुलेसन हेडर, बाहिरी IP हेडर, यातायात हेडर र कुनै पनि प्रमाणीकरण ट्यागले भित्री प्याकेटले प्रयोग गर्न नसक्ने बाइट खर्च गर्छन्। टनेल इन्टरफेस 1500 मा राख्नुभयो भने बाहिरी प्याकेट मार्गले बोक्न सक्नेभन्दा नियमित रूपमा बढी हुन्छ। 'खण्ड नगर्नु' बिट सेट भएपछि राउटरले त्यसलाई छोड्छ र ICMP त्रुटि फर्काउनुपर्छ; त्यो त्रुटि फिल्टर भयो भने पठाउनेलाई कहिल्यै थाहा हुँदैन।

त्यसैले असफलता छनोट जस्तो देखिन्छ। साना अनुरोध पूरा हुन्छन् र खण्ड भर्ने जुनसुकै कुरा अड्किन्छ, किनकि ठूला प्याकेट मात्र छोडिन्छन्। पिङ पार गर्ने टनेल डेटा बोक्ने टनेल होइन।

MSS क्ल्याम्पिङ र त्यो कहाँ लागू हुन्छ

MSS क्ल्याम्पिङले छानिएको बिन्दु पार गर्दा SYN खण्डको मान पुनःलेख्छ, जसले दुवै छेउलाई किन भनेर नजानी सानो पेलोड छान्न बनाउँछ। Linux मा यो स्पष्ट नियमले लागू गर्ने mangle तालिकाको लक्ष्य हो, र यसले तपाईंले चाहेको दिशामा SYN प्याकेटमा लाग्नुपर्छ। यसलाई टनेल इन्टरफेस र ठेगाना दायरामा सीमित राख्नुहोस्, किनकि फराकिलो नियमले टनेलमा कहिल्यै नपस्ने ट्राफिकको व्यवहार बदल्छ।

प्रभाव TCP मा मात्र। UDP अनुप्रयोग, QUIC सत्र र आफ्नै डेटाग्राम बनाउने कुनै पनि प्रोटोकल यसबाट अछूत रहन्छ।

स्थिर मार्गले निदान गर्नुहोस्

एक पटकमा एउटा चर राख्नुहोस्। तपाईं आफैं आकार छान्ने प्याकेटले परीक्षण गर्नुहोस्, र कर्नेलले नतिजा लुकाउनुको सट्टा जनाउन 'खण्ड नगर्नु' झन्डा सेट गर्नुहोस्।

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

हरेक परिवर्तनले के सुधार्दैन

इन्टरफेसको MTU घटाउँदा पहिल्यै स्थापित सत्रको MSS बदलिँदैन। MSS सीमित गर्दा UDP प्रवाहलाई मद्दत गर्दैन, र ICMP त्रुटि एउटै दिशामा मात्र फिल्टर हुने मार्ग सुधार्दैन। हरेक परिवर्तनले समस्याको एउटा वर्ग सुधार्छ र बाँकी जस्ताको तस्तै छाड्छ।

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