किसी गाइड में कहीं एक संख्या होती है, आम तौर पर साठ से अस्सी बाइट के बीच, जिसे किसी ने 1500 से घटाकर इंटरफ़ेस MTU निकाला था। वह संख्या एक खास पथ पर एक खास एनकैप्सुलेशन का वर्णन करती है। मोड, बाहरी पता परिवार, साइफ़र या NAT की मौजूदगी बदलिए, और गणित अब आपके टनल पर लागू नहीं होती।

यह संख्या किसी दूसरे टनल से आई थी

ओवरहेड अमूर्त रूप में IPsec का गुण नहीं है। यह उस पैकेट का गुण है जो वास्तव में बनता है: तय किया गया मोड, बाहरी हेडर, सुरक्षा हेडर, पैडिंग, एक इंटीग्रिटी फ़ील्ड और संभवतः एक अतिरिक्त UDP आवरण।

IPv4 के साथ और NAT के बिना ट्रांसपोर्ट मोड के लिए बताई गई संख्या NAT ट्रैवर्सल के तहत IPv6 वाले टनल मोड से छोटा पैकेट बताती है। दोनों अपने-अपने मामले के लिए सही हैं। इनमें से किसी एक को किसी दूसरे परिनियोजन में कॉपी करना ही वह रास्ता है जिससे लोगों के पास ऐसा MTU आ जाता है जो बड़े स्थानांतरण तोड़ देता है। विफलता शांत रहती है, क्योंकि छोटे अनुरोध चलते रहते हैं।

जो परतें सचमुच मौजूद हैं उन्हें जोड़िए

बाहरी IP हेडर से शुरू कीजिए और भीतर की ओर बढ़िए। टनल मोड में मूल पैकेट भीतर होता है, इसलिए बाहरी हेडर बदलाव नहीं बल्कि जोड़ है। RFC 4303 ESP हेडर, पैडिंग और उसके बाद आने वाले इंटीग्रिटी डेटा का वर्णन करता है।

LayerWhat it addsWhen it applies
Outer IP header20 bytes for IPv4, 40 for IPv6Always, and 40 rather than 20 if the outer path is v6
ESP header8 bytes of SPI and sequence numberAlways
Block cipher IV8 to 16 bytes depending on the transformWhen the negotiated cipher uses one
Padding and trailerPadding to the block size, plus two trailer bytesAlways, and the amount varies with payload length
Integrity data12 to 16 bytes for common authenticated ciphersWhen integrity protection is negotiated
UDP encapsulation8 bytesNAT traversal on port 4500, which is common for clients behind NAT

उनमें से कोई भी पंक्ति परिनियोजनों के बीच स्थिर नहीं है, और पैडिंग वाली पंक्ति एक ही परिनियोजन के भीतर भी स्थिर नहीं है। एक ही प्रकाशित ओवरहेड संख्या निराश करती है, इसका पूरा कारण यही है।

दो साइटें एक ही टनल पर असहमत हो सकती हैं

सुरक्षित पैकेट को अब भी बाहरी पथ पार करना है, और बाहरी पथ हर जगह एक जैसा नहीं है। PPPoE एक्सेस लिंक साफ़ Ethernet सेगमेंट से कम ढोता है। मोबाइल नेटवर्क और सिकुड़ सकता है, और अपना ट्रैफ़िक टनल करने वाला प्रदाता एक और एनकैप्सुलेशन जोड़ देता है जिसका किसी ने ज़िक्र नहीं किया। जो टनल एक लिंक पर चलता है और दूसरे पर विफल हो जाता है, वह दूसरे लिंक का वर्णन कर रहा है, प्रोटोकॉल का नहीं।

दोनों दिशाएँ भी अलग हो सकती हैं। असममित मार्ग आपको चलता हुआ अपलोड और अटका हुआ डाउनलोड दे सकता है, जो तब तक एप्लिकेशन की समस्या जैसा लगता है जब तक आप पहुँच के बजाय पैकेट के आकार न देखें। छोटा ping सफल होना पूरे आकार के उत्तर के बारे में बहुत कम साबित करता है।

घटाने के बजाय नापिए

पथ से गुज़रने वाला सबसे बड़ा डेटाग्राम खोजिए। फिर उसकी तुलना इंटरफ़ेस के बताए मान से कीजिए:

ip link show eth0 | grep -o 'mtu [0-9]*'
ip xfrm state list
ping -M do -s 1400 198.51.100.7
ping -M do -s 1372 198.51.100.7
tcpdump -ni any -c 20 'esp or udp port 4500'

ping का आकार तब तक घटाइए जब तक उत्तर न आने लगें, और सबसे बड़े चलने वाले मान को उस पथ का बजट मानिए। xfrm का आउटपुट बताता है कि कौन-सा मोड और कौन-से एल्गोरिदम तय हुए, और यही किसी भी ईमानदार गणना का इनपुट है। कैप्चर पुष्टि करता है कि तार पर ESP है या UDP में लिपटा ESP, और इससे NAT का सवाल अनुमान के बिना हल हो जाता है।

कंट्रोल प्लेन के लिए भी एक मान अलग रखिए। IKE हैंडशेक पैकेट की बनावट डेटा पैकेट से अलग होती है, इसलिए हैंडशेक कैप्चर से निकाला गया आकार डेटा प्लेन का MTU नहीं है।

संख्या को उसकी जगह रखिए

टनल से गुज़रने वाले TCP के लिए, MSS क्लैंप अक्सर सबसे कम हस्तक्षेप करने वाला नियंत्रण है, क्योंकि यह टनल को ही बदले बिना सिरों के भेजे जाने वाले डेटा को घटा देता है। मार्ग-आधारित टनल के लिए, टनल इंटरफ़ेस का MTU जानबूझकर तय कीजिए और क्यों, यह दर्ज कीजिए। दोनों एक साथ करके फिर नापने से आपको यह पता नहीं चलता कि किसने मदद की।

टिकट में तय मोड, बाहरी परिवार, NAT की स्थिति और दोहराया जा सकने वाला लक्षण साथ रखिए। चार तथ्यों का दर्ज समूह याद रखे गए स्थिरांक से बेहतर है, और अगले क्लाइंट अपग्रेड तक टिकने वाला यही एकमात्र संस्करण है।

संबंधित लेख