VPN गेटवे पर MSS क्लैंपिंग: यह क्या ठीक करती है और क्या नहीं
क्लैंपिंग TCP हैंडशेक में MSS को फिर से लिखती है ताकि सेगमेंट टनल में फ़िट हों। यह कभी भी UDP या खराब path-MTU जाँच को ठीक नहीं करती। तीन जाँचें, क्रम में।
छोटे अनुरोध काम करते हैं, बड़े डाउनलोड अटक जाते हैं, और कोई MSS क्लैंपिंग सुझाता है। यह सुझाव इतना अक्सर सही होता है कि सही क्रम में आज़माने लायक हो, और इतना अक्सर ग़लत होता है कि बिना सोचे लागू करने पर पूरी दोपहर बर्बाद हो जाए। नीचे की तीन जाँचें असली TCP आकार की समस्या को UDP समस्या, टूटी path-MTU खोज, और ऐसी क्लैंप से अलग करती हैं जो उस हैंडशेक को कभी नहीं देखती जिसे उसे फिर से लिखना है।
विफलता के आकार से शुरू करें
आकार की विफलता की एक पहचान होती है: कनेक्शन बनता है, प्रमाणीकरण और छोटे उत्तर सफल होते हैं, और फिर पूर्ण आकार के सेगमेंट की ज़रूरत पड़ते ही स्थानांतरण अनिश्चित काल के लिए रुक जाता है। जो पेज टेक्स्ट लोड करते हैं पर छवि कभी पूरी नहीं करते, वे छोटे पैमाने पर वही विफलता हैं। अगर कुछ भी कनेक्ट ही न हो, तो समस्या रास्ते में पहले है और क्लैंपिंग मदद नहीं करेगी। क्लैंप उस हैंडशेक को ठीक नहीं कर सकती जो कभी पहुँचा ही नहीं।
यह पहचान इसलिए है क्योंकि सेगमेंट का आकार हैंडशेक में ही तय होता है। हर पक्ष TCP विकल्प के रूप में अधिकतम सेगमेंट आकार की घोषणा करता है, और प्रेषक सामने वाले की घोषणा का सम्मान करते हैं। अगर रास्ता इतना बड़ा सेगमेंट नहीं ढो सकता, तो विफलता बाद में दिखती है, जब प्रेषक आखिर में एक आज़माता है।
इस लक्षण को पढ़ते समय परिवहन को ध्यान में रखें। क्लैंपिंग TCP विकल्प का पुनर्लेखन है, इसलिए उसी टनल के नीचे अटकने वाली वॉइस या वीडियो कॉल MSS समस्या नहीं है और उससे बेहतर नहीं होगी। किसी TCP विकल्प को छूने से पहले परिवहन लिख लें।
रास्ते का दाम लगाएँ, फिर टनल से तुलना करें
दो संख्याएँ मायने रखती हैं और अक्सर गड्डमड्ड हो जाती हैं। path-MTU वह सबसे बड़ा पैकेट है जो रास्ता बिना विखंडन के ढोएगा, और IPv4 के लिए घोषित MSS वह मान घटाकर IP और TCP हेडर के 40 बाइट है, या IPv6 के लिए 60 घटाकर। टनल एनकैप्सुलेशन अंदरूनी पैकेट शुरू होने से पहले ही बजट का एक हिस्सा खा जाता है।
ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20do-not-fragment बिट वाला ping बताता है कि उस पेलोड आकार का पैकेट बचता है या नहीं; आकार बदलते रहें जब तक वह विफल न हो और आपने अनुभवजन्य रूप से रास्ते की सीमा पा ली। tracepath का आउटपुट मार्ग में खोजा गया MTU बताता है, जो काम करने पर तेज़ और बीच का हॉप जाँचों को फ़िल्टर करने पर कम भरोसेमंद होता है।
अब टनल का ओवरहेड घटाएँ। बाहरी IP हेडर, UDP हेडर और टनल-विशिष्ट हेडर सब उन्हीं 1500 बाइट में से आते हैं, इसलिए सामान्य ईथरनेट अंडरले पर उपयोगी अंदरूनी MTU भौतिक लिंक के संकेत से कम होता है। अगर गणना किया गया अंदरूनी MTU आपके साथियों की घोषणा से कम है, तो आपने अनुमान नहीं बल्कि असली क्लैंप उम्मीदवार पाया है। अगर गणना किया गया मान पहले से ही साथियों की घोषणा से ऊपर है, तो यहीं रुकें और कहीं और देखें।
क्लैंप वहाँ रखें जहाँ से हैंडशेक गुज़रता है
क्लैंप गेटवे पार करते समय SYN और SYN-ACK पैकेट में MSS विकल्प को फिर से लिखकर काम करती है। अगर नियम ऐसे इंटरफ़ेस पर है जिसे कोई भी दिशा कभी पार नहीं करती, तो बातचीत बिना बदलाव के पूरी हो जाती है और लक्षण बना रहता है, इसलिए मान से ज़्यादा जगह परिणाम तय करती है।
| Symptom | What it points to | Next check |
|---|---|---|
| Handshake completes, large transfer stalls | Segment size larger than the path can carry | Path MTU against the tunnel's effective MTU |
| Nothing connects, small or large | Routing, firewall or keying failure | Not MSS; look at the tunnel state |
| Only UDP applications stall | Datagram size or a dropped ICMP error | Platform-specific UDP handling, not clamping |
| Fixed after reconnect, returns later | Clamp applied to one direction or one interface | Rule placement and the handshake path |
दिशा दूसरा आधा हिस्सा है। एक दिशा की क्लैंपिंग आधे प्रवाह ठीक करती है और बाकी को ऐसे विफल छोड़ती है जो रुक-रुककर लगता है, इसलिए इसे अग्रेषित ट्रैफ़िक की दोनों दिशाओं पर लगाएँ। टनल इंटरफ़ेस के लिए Linux का पारंपरिक रूप SYN पैकेट से मेल खाने वाला mangle नियम है:
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuध्यान दें कि --clamp-mss-to-pmtu असल में क्या करता है: यह मान रूट के MTU से निकालता है, जो हमेशा टनल का असली पेलोड बजट नहीं होता। रूट-आधारित टनल में जहाँ अंदरूनी रूट और बाहरी रास्ता अलग होते हैं, पिछली जाँच में गणना किया गया स्पष्ट मान स्वचालित मान से ज़्यादा अनुमानयोग्य होता है।
नए कनेक्शन से सत्यापित करें और प्रतिक्रिया जीवित रखें
स्थापित कनेक्शन अपना बातचीत किया हुआ MSS बनाए रखता है, इसलिए उसी सत्र में परीक्षण कुछ सिद्ध नहीं करता। बदलाव के बाद नया कनेक्शन खोलें और बातचीत किया गया मान सीधे पढ़ें, बजाय संयोग से पूरी होने वाली किसी स्थानांतरण से अनुमान लगाने के।
ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSSपहला कमांड सॉकेट का MSS उसकी कंजेशन स्थिति के साथ बताता है, जो सबसे तेज़ पुष्टि है कि क्लैंप असर कर गई। दूसरा पुष्टि करता है कि जो नियम आपने जोड़ा समझा वही मौजूद है, उसी तालिका में जहाँ वह रखा गया।
फिर उस तंत्र की रक्षा करें जिसे आपने ठीक नहीं किया। path-MTU खोज इस पर निर्भर है कि ICMP fragmentation-needed संदेश प्रेषक तक पहुँचें, इसलिए उन्हें गिराने वाला फ़ायरवॉल सही क्लैंप होने पर भी बड़े स्थानांतरण तोड़ता रहेगा। टनल मार्ग के लिए उन संदेशों की अनुमति दें, या स्वीकारें कि क्लैंपिंग आपकी चुनी हुई नीति की भरपाई कर रही है।
अंत में, क्लैंप को ट्यूनिंग नॉब मानने के लोभ का विरोध करें। यह सेगमेंट का आकार सीमित करती है, जिससे उन रास्तों पर थ्रूपुट का खर्च आता है जिन्हें इसकी कभी ज़रूरत ही नहीं थी। तीन जाँचों के बाद लगाई गई यह लक्षित मरम्मत है; पहले लगाई गई यह ऐसा बदलाव है जो मूल खराबी छिपा देता है और हर बाद के परीक्षण में दूसरा चर जोड़ देता है। यह सौदा जानबूझकर करना चाहिए, डिफ़ॉल्ट से नहीं।
जो path-MTU आपने मापा, जो टनल ओवरहेड घटाया, जो नियम जोड़ा और बाद में जो MSS देखा, वह लिख लें। चार संख्याएँ अगली घटना को जाँच के बजाय खोज बना देती हैं।