Linux IPsec गेटवे पर TCP MSS क्लैंपिंग: यह क्या ठीक करती है

Ping काम करता है, SSH काम करता है, एक छोटा पृष्ठ लोड होता है, और फिर हर बड़ा उत्तर समय समाप्त होने तक अटक जाता है। पुराना पैटर्न पहुँच क्षमता नहीं, पैकेट के आकार की ओर इशारा करता है: पथ हैंडशेक और पहले कुछ किलोबाइट ले जाता है, फिर पूर्ण आकार का सेगमेंट गायब हो जाता है। Linux IPsec गेटवे पर TCP MSS नियम अक्सर समाधान होता है, लेकिन केवल तब जब आप समझें कि यह क्या बदलता है और यह जिस पैकेट को छूता है वह वास्तव में कहाँ है। नीचे का क्रम लक्षण से नियम की जगह तक पैकेट का पीछा करता है, ताकि व्याख्या फिट होना बंद करते ही आप रुक सकें।

वह लक्षण जो MSS की ओर संकेत करता है

TCP हैंडशेक में अधिकतम सेगमेंट आकार पर बातचीत करता है। यदि वह मान एनकैप्सुलेशन के बाद पथ जितना ले जा सकता है उससे बड़ा है, तो प्रेषक ऐसे सेगमेंट बनाता रहता है जो कभी नहीं पहुँचते, और पहले दौर के बाद कनेक्शन अटक जाता है। छोटे उत्तर फिट होते हैं; बड़े नहीं।

ICMP प्रतिक्रिया पथ-MTU खोज के ज़रिए कनेक्शन को बचा सकती है, और इन संदेशों को गिराने वाला फ़ायरवॉल अटकाव को एक शांत ब्लैक होल में बदल देता है। इसीलिए वही टनल एक एप्लिकेशन के लिए काम करता है और दूसरे के लिए कॉन्फ़िगरेशन में कोई स्पष्ट अंतर के बिना विफल हो जाता है।

TCPMSS नियम क्या करता है और क्या नहीं

नियम गुज़रते समय TCP हैंडशेक पैकेटों में MSS विकल्प को फिर से लिखता है। यह टनल इंटरफ़ेस का MTU सेट नहीं करता, IPsec नीति नहीं बदलता, और वर्तमान कर्नेल पर केवल घोषित मान को घटाता है, पहले से छोटे मान को बढ़ाता नहीं। यह केवल TCP को छूता है; UDP पेलोड, DNS व्यवहार और बातचीत किए गए ट्रैफ़िक सिलेक्टर इसकी पहुँच से बाहर हैं।

चूँकि बदलाव हैंडशेक के दौरान होता है, नियम से पहले स्थापित मौजूदा कनेक्शन अपना पुराना मान बनाए रखता है। नए कनेक्शन से परीक्षण करें, और अपेक्षा करें कि बदलाव के बाद का पहला प्रयास ही आपको कुछ बताएगा। नियम में कुछ भी पहले से खुले कनेक्शन तक नहीं पहुँचता। इसीलिए किसी घटना के बीच में लागू सुधार ऐसा लग सकता है जैसे उसने कुछ भी नहीं किया।

नियम को आंतरिक TCP पथ पर रखें

नीति-आधारित Linux गेटवे पर, फ़ायरवॉल जब अग्रेषित पैकेट देखता है तब भी वह सामान्य TCP जैसा दिखता है। IPsec नीति तय करती है कि पैकेट सुरक्षित होगा; फ़ायरवॉल आंतरिक प्रवाह के लिए ESP हेडर नहीं देखता, इसलिए यहाँ ESP से मिलान एक पूरी तरह अलग पैकेट का वर्णन करता है। यही असंगति कारण है कि कुछ नियम सही दिखते हैं और कभी मेल नहीं खाते।

iptables की शब्दावली में नियम अग्रेषण पथ की mangle तालिका में आता है, हैंडशेक पैकेटों तक सीमित: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270। संख्या एक उदाहरण है, सार्वभौमिक स्थिरांक नहीं; इसे एनकैप्सुलेशन ओवरहेड और पथ के वास्तविक MTU से निकालें। nftables का समकक्ष forward या postrouting श्रृंखला में अधिकतम सेगमेंट आकार सेट करता है।

IKE और ESP के बाहरी श्रवण नियमों को आंतरिक अग्रेषण नियमों से अलग रखें। एक ही नियम जो एप्लिकेशन प्रवाह और बाहरी प्रोटोकॉल दोनों को अधिकृत करने का प्रयास करता है, अंत में किसी के भी साथ भरोसेमंद मेल नहीं खाता।

फ़ायरवॉल के स्वामी और NAT क्रम का सम्मान करें

यदि UFW होस्ट फ़ायरवॉल का स्वामी है, तो mangle और अग्रेषण परिवर्तन उसके समर्थित स्थायी कॉन्फ़िगरेशन के ज़रिए जोड़ें, अगली बार पुनः लोड होने पर गायब हो जाने वाला आदेश टाइप करने के बजाय। गलत तालिका में या किसी अंतिम नियम के बाद डाला गया नियम कोई प्रभाव नहीं डालता, और जीवंत तालिका यह आपसे छिपा देती है।

स्रोत अनुवाद एक अलग निर्णय है जो अक्सर इसके साथ अंतःक्रिया करता है। सामान्य masquerade नियम से पहले रखी गई छूट सुरक्षित ट्रैफ़िक को उस स्रोत को खोने से बचाती है जिसकी उसकी नीति मांग करती है; यह आकार की समस्या नहीं सुधारती, और आकार का नियम अनुवाद की समस्या नहीं सुधारता।

संकीर्ण रूप से सत्यापित करें, फिर रुकें

विफल सेवा के लिए नया कनेक्शन खोलें और एप्लिकेशन तथा नियम के काउंटर दोनों पर नज़र रखें। यदि अटकाव दूर हो जाता है, तो उस एनकैप्सुलेशन के साथ उस TCP पथ के बारे में आपके पास प्रमाण है। आपके पास इस बात का प्रमाण नहीं है कि हर VPN प्रोटोकॉल फिट होता है, हर UDP एप्लिकेशन ठीक हो गया है, या कोई विशिष्ट अपस्ट्रीम सेवा मूल कारण थी।

जहाँ नीति अनुमति दे वहाँ ICMP आकार-प्रतिक्रिया काम करने दें, और जब बाहरी IPsec पथ आंतरिक रूट द्वारा प्रदर्शित न हो तो रूट-MTU आधारित स्वचालित क्लैंपिंग के साथ सावधानी बरतें। निष्कर्ष जितना संकीर्ण होगा, अगली घटना का निदान उतना ही आसान होगा।