NAT ट्रॅव्हर्सल ESP ला UDP मध्ये कसे गुंडाळते

एकाच राउटरमागील दोन क्लायंट एका IPsec गेटवेशी बोलतात, आणि एक सतत कमी होतो तर दुसरा जोडलेला राहतो। मूळ ESP हा पोर्ट नसलेला 50 वा IP प्रोटोकॉल आहे, म्हणून अनेक क्लायंट एकच पत्ता सामायिक करतात तेव्हा अनुवादकाकडे मॅपिंगला आधार देण्यासारखे काही नसते। 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 च्या नोट्स दोन्ही टप्प्यांमागील एन्कॅप्स्युलेशन आणि जिवंत ठेवण्याच्या सेटिंग्ज समाविष्ट करतात।