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 लेख्नुहोस्। चार संख्याले अर्को घटनालाई जाँचको सट्टा खोज बनाउँछन्।