कैसे NAT ट्रैवर्सल ESP को UDP के भीतर लपेटता है

एक ही राउटर के पीछे के दो क्लाइंट एक ही IPsec गेटवे से बात करते हैं, और एक लगातार गिरता रहता है जबकि दूसरा जुड़ा रहता है। मूल ESP IP प्रोटोकॉल 50 है जिसके कोई पोर्ट नहीं होते, इसलिए जब कई क्लाइंट एक ही पता साझा करते हैं तो अनुवादक के पास मैपिंग को टिकाने के लिए कुछ नहीं होता। NAT ट्रैवर्सल 4500 पर ESP को UDP के भीतर लपेटकर यह अंतराल भरता है, और वह हेडर आगे आने वाले अधिकांश लक्षणों को समझाता है। यह उस उपकरण की ओर भी इशारा करता है जिसे बदलना है।

डेटा तल 4500 पोर्ट पर क्यों जाता है

सेटअप के दौरान IKEv2 उन पतों और पोर्टों की तुलना करता है जिन्हें हर पक्ष इस्तेमाल करने के बारे में सोचता है, अपनी NAT पहचान अधिसूचनाओं में हैश का आदान-प्रदान करके। जब हैश मेल नहीं खाते, तो पथ में कहीं एक अनुवादक बैठा होता है, और दोनों साथी संरक्षित ट्रैफ़िक को UDP एनकैप्सुलेशन पर ले जाते हैं। इसलिए जो सत्र अनुवादक से टकराया है वह उस सत्र से अलग दिखता है जो नहीं टकराया।

लपेट एक लिफ़ाफ़ा है, प्रोटोकॉल का बदलाव नहीं: ESP अपना हेडर, अखंडता जाँच और एन्क्रिप्शन बनाए रखता है, और UDP केवल वे पोर्ट देता है जिनकी अनुवादक को ज़रूरत है। पोर्ट 500 IKE अदला-बदली ले जाता है; 4500 पहचान के बाद लिपटा डेटा और अक्सर बाद के IKE संदेश भी ले जाता है। कोई भी पोर्ट प्रवाह को TCP कनेक्शन नहीं बनाता, यही धारणा कैप्चर पढ़ने वाले अधिकांश लोगों को भटकाती है।

दोनों चरणों को क्रम में जाँचें

पहले नियंत्रण अदला-बदली साबित करें, फिर डेटा पथ, और दोनों को अपने नोट्स में अलग रखें। जो कैप्चर 500 पर ट्रैफ़िक दिखाता है और 4500 पर कभी नहीं, आमतौर पर इसका मतलब है कि डेटा पथ फ़िल्टर हो रहा है, इसलिए सुधार क्लाइंट में नहीं, फ़ायरवॉल नियम में करना है।

tcpdump -ni any 'udp port 500 or udp port 4500' के साथ दोनों पोर्ट देखें, और सत्र के चालू रहते राउटर पर अनुवाद तालिका पढ़ें। वह तालिका वह स्रोत पोर्ट दिखाती है जो गेटवे वास्तव में देखेगा, और लैपटॉप पर कैप्चर जानबूझकर उससे अलग है: लैपटॉप 500 मानता है जबकि गेटवे अनुवादित स्रोत पोर्ट के साथ 4500 देखता है, और दोनों सही हैं। वही प्रवाह, अनुवाद से पहले और बाद में:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

लपेट किन लक्षणों को समझाता है, और किन दो को नहीं

ऐसा राउटर जो नियंत्रण अदला-बदली की अनुमति देता है और लिपटे डेटा को अवरुद्ध करता है 'टनल ऊपर है पर कुछ नहीं गुज़रता' वाली रिपोर्ट बनाता है। मैपिंग तालिकाएँ समाप्त हो जाती हैं, इसलिए निष्क्रिय सत्र को दोनों पक्षों द्वारा जानबूझकर भेजे गए जीवित रखने वाले ट्रैफ़िक की ज़रूरत होती है, और वे पैकेट स्वास्थ्य जाँच नहीं हैं। जब एक गेटवे के पीछे कई क्लाइंट एक साथ विफल होते हैं, तो उस गेटवे का अनुवाद और कोई पुरानी पासथ्रू सुविधा जाँचें। लपेट उस एप्लिकेशन को नहीं समझाता जो टनल उठने के बाद हर क्लाइंट पर विफल होता है, और न ही ब्लॉक पृष्ठ पर प्रमाणपत्र चेतावनी को; दोनों इस परत के ऊपर हैं।

एक बार में दो क्लाइंट के लिए मैपिंग तालिका पढ़ें: अगर दोनों एक ही अनुवादित पोर्ट दिखाते हैं, तो उपकरण उन्हें उस तरह अलग नहीं कर रहा जैसे गेटवे को चाहिए। जो पासथ्रू मोड केवल एक होस्ट को मूल ESP देता है वह कई अनुवादित क्लाइंट की सेवा के बराबर नहीं है, हालाँकि विक्रेता दोनों को IPsec-अनुकूल बताते हैं। दोहरा NAT मैपिंग की एक परत और एक और समाप्ति बिंदु जोड़ता है, लेकिन बाहर जाने वाले कनेक्शन अपने आप नहीं तोड़ता।

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

मैपिंग का स्वामी बदलें, फिर दोबारा परखें

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

किसी भी बदलाव के बाद दोनों चरण जाँच दोहराएँ और पुष्टि करें कि डेटा पैकेट गुज़र रहा है, केवल यह नहीं कि स्थिति स्क्रीन हरी हो गई। ट्यूपल, मैपिंग तालिका का आउटपुट और नियम का बदलाव एक ही नोट में रखें, ताकि अगला व्यक्ति नियंत्रण अदला-बदली से फिर शुरू न करे। NAT ट्रैवर्सल पर strongSwan के नोट्स दोनों चरणों के पीछे की एनकैप्सुलेशन और जीवित रखने की सेटिंग्स को कवर करते हैं।