IPsec ओव्हरहेड: मोड, NAT-T आणि अल्गोरिदम सर्व ते बदलतात
प्रकाशित एक ओव्हरहेड संख्या एका मार्गावरील एकाच एन्कॅप्स्युलेशनचे वर्णन करते. तुमचा टनेल प्रत्यक्षात ज्या हेडरवर सहमत होतो त्या जोडा, नंतर मार्ग मोजा.
कोणत्यातरी मार्गदर्शकात एक संख्या असते, सहसा साठ ते ऐंशी बाइट्समध्ये, जी कोणीतरी 1500 मधून वजा करून इंटरफेस MTU मिळवली होती। ती संख्या एका विशिष्ट मार्गावरील एका विशिष्ट एन्कॅप्स्युलेशनचे वर्णन करते। मोड, बाह्य पत्ता कुटुंब, सिफर किंवा NAT ची उपस्थिती बदला, आणि गणित आता तुमच्या टनेलला लागू होत नाही।
ती संख्या दुसऱ्या टनेलमधून आली
ओव्हरहेड अमूर्त अर्थाने IPsec चा गुणधर्म नाही। तो प्रत्यक्षात तयार होणाऱ्या पॅकेटचा गुणधर्म आहे: ठरलेला मोड, बाह्य हेडर, संरक्षण हेडर, पॅडिंग, अखंडता क्षेत्र आणि कदाचित अतिरिक्त UDP आवरण।
IPv4 सह आणि NAT शिवाय ट्रान्सपोर्ट मोडसाठी नमूद केलेली संख्या NAT ट्रॅव्हर्सलअंतर्गत IPv6 असलेल्या टनेल मोडपेक्षा लहान पॅकेटचे वर्णन करते। दोन्ही आपल्या केससाठी बरोबर आहेत। यापैकी एक दुसऱ्या परिनियोजनात कॉपी करणे हाच मार्ग लोक मोठ्या हस्तांतरणांचे नुकसान करणाऱ्या MTU पर्यंत पोहोचतात। लहान विनंत्या चालू राहतात म्हणून अपयश शांत असते।
प्रत्यक्षात असलेले स्तर जोडा
बाह्य IP हेडरपासून सुरुवात करा आणि आत जा। टनेल मोडमध्ये मूळ पॅकेट आत असते, म्हणून बाह्य हेडर बदल नाही तर जोड आहे। RFC 4303 ESP हेडर, पॅडिंग आणि त्यानंतर येणाऱ्या अखंडता डेटाचे वर्णन करते।
| Layer | What it adds | When it applies |
|---|---|---|
| Outer IP header | 20 bytes for IPv4, 40 for IPv6 | Always, and 40 rather than 20 if the outer path is v6 |
| ESP header | 8 bytes of SPI and sequence number | Always |
| Block cipher IV | 8 to 16 bytes depending on the transform | When the negotiated cipher uses one |
| Padding and trailer | Padding to the block size, plus two trailer bytes | Always, and the amount varies with payload length |
| Integrity data | 12 to 16 bytes for common authenticated ciphers | When integrity protection is negotiated |
| UDP encapsulation | 8 bytes | NAT 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 स्थिती आणि पुनरावृत्ती होणारे लक्षण एकत्र ठेवा। चार तथ्यांचा नोंदवलेला संच लक्षात ठेवलेल्या स्थिरांकापेक्षा चांगला आहे, आणि पुढील क्लायंट अपग्रेडपर्यंत टिकणारी हीच एकमेव आवृत्ती आहे।