IPsec ओभरहेड: मोड, NAT-T र एल्गोरिदम सबैले यसलाई बदल्छन्
प्रकाशित एउटा ओभरहेड संख्याले एउटै मार्गमा एउटै इन्क्याप्सुलेसनको वर्णन गर्छ। तपाईंको टनेलले साँच्चै कुरा मिलाउने हेडरहरू जोड्नुहोस्, त्यसपछि मार्ग नाप्नुहोस्।
कुनै गाइडमा कतै एउटा संख्या हुन्छ, सामान्यतया साठीदेखि असी बाइटसम्म, जसलाई कसैले इन्टरफेस MTU पाउन 1500 बाट घटाएको थियो। त्यो संख्याले एउटा निश्चित मार्गमा एउटा निश्चित इन्क्याप्सुलेसनको वर्णन गर्छ। मोड, बाहिरी ठेगाना परिवार, साइफर वा 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 स्थिति र फेरि देखा पर्ने लक्षण सँगै राख्नुहोस्। चार तथ्यहरूको अभिलेखित समूह सम्झिएको स्थिरांकभन्दा राम्रो हुन्छ, र अर्को क्लाइन्ट अपग्रेडसम्म टिक्ने यही एउटै संस्करण हो।