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 आधारित स्वयंचलित क्लॅम्पिंग काळजीपूर्वक हाताळा। निष्कर्ष जितका बारीक, पुढील घटनेचे निदान तितके सोपे।