IPsec मध्ये IPsec: बाहेरील बोगद्याने कोणते पत्ते वाहून न्यावेत

नेस्टेड IPsec बद्दल विचार करणे सोपे होते जेव्हा दोन्ही स्तर वेगवेगळ्या मशीनवर संपतात. चार गेटवे, दोन बोगदे आणि रचना काम करते की नाही हे ठरवणारा एकच प्रश्न: आतील बोगद्याने पॅकेट संपवल्यावर बाहेरील बोगदा खरंच काय पाहतो? त्याचे उत्तर द्या आणि निवडक, मार्ग आणि समस्या निवारणाचा क्रम आपोआप येतो. चूक केली तर तांत्रिकदृष्ट्या सुरू असलेल्या बोगद्याचे डीबगिंग करण्यात तुम्ही एक दिवस घालवाल.

चार गेटवेचे मॉडेल

बाहेरील गेटवे A आणि B दोन साइट्समध्ये पहिला बोगदा बांधतात. A च्या मागे ट्रान्झिट पत्ता 10.60.0.2 असलेला आतील गेटवे C, आणि B च्या मागे ट्रान्झिट पत्ता 10.70.0.2 असलेला आतील गेटवे D आहे. ॲप्लिकेशन नेटवर्क C आणि D च्या मागे आहेत, आणि उदाहरणातील प्रत्येक पत्ता जाणूनबुजून आच्छादित नाही.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

स्तर चार होस्टमध्ये विभागणे म्हणजे प्रत्येक मशीन एक सीमा लागू करते. दोन्ही स्तर एकाच होस्टवर चालवताना एकाच मशीनवर दोन धोरण संच, दोन मार्ग सारण्या आणि दोन अपयश पद्धती जुळवाव्या लागतात, जे शक्य आहे आणि निरीक्षण करणे खूप कठीण आहे.

प्रत्येक स्तर फक्त स्वतःचे संरक्षण काढून टाकतो

C, D साठी ॲप्लिकेशन पॅकेट एन्क्रिप्ट करतो. निकाल C कडून D कडे पत्ता दिला जातो, आणि तोच A पर्यंत पोहोचतो. पुढील सर्व काही त्या पुनर्लेखनावर अवलंबून आहे.

A ते B साठी पुन्हा एन्क्रिप्ट करतो. B बाहेरील स्तर डिक्रिप्ट करतो, C कडून D कडे जाणारे पॅकेट पाहतो आणि ते अजूनही एन्क्रिप्टेड असलेले पुढे पाठवतो. D आतील संरक्षण काढून ॲप्लिकेशन पॅकेट पोहोचवतो.

त्यामुळे A आणि B आतील टोकांचे आणि त्यांच्या मेटाडेटाचे पाहतात, पण ॲप्लिकेशन पेलोड डिक्रिप्ट करणारे पक्ष ते नाहीत. हे रचनेचे खरे वैशिष्ट्य आहे, C, D किंवा ॲप्लिकेशन होस्ट विश्वासार्ह आहेत असा दावा नाही.

बाहेरील निवडक आतील गेटवेची नावे देतात

इथेच अशा बांधण्यांपैकी बहुतेक अपयशी होतात. धोरण-आधारित बाहेरील बोगद्यासाठी, तुम्ही वाटाघाटी करता त्या निवडकांमध्ये A आणि B प्रत्यक्षात हाताळतात ते पत्ते असले पाहिजेत: 10.60.0.2/32 आणि 10.70.0.2/32, योग्य स्थानिक आणि दूरस्थ क्रमाने.

अंतिम ॲप्लिकेशन सबनेट बाहेरील निवडकांमध्ये ठेवणे चालत नाही, कारण पॅकेट A पर्यंत पोहोचेपर्यंत आतील एन्कॅप्सुलेशनने A ला संरक्षित करायच्या गोष्टी आधीच पुनर्लिखित केल्या असतात. मग बाहेरील धोरण कशाशीही जुळणार नाही, आणि बोगदा कोणताही डेटा न वाहता वर येईल.

बाहेरील परवानगी UDP 500 पर्यंत अरुंद करू नका. आतील कनेक्शनला स्वतःचा डेटा मार्ग आहे, जो वाटाघाटीनुसार ESP किंवा UDP एन्कॅप्सुलेशन वापरतो, आणि बाहेरील धोरणाने तो प्रोटोकॉल परवानगी दिली पाहिजे.

प्रत्येक गेटवेवर swanctl --list-sas वापरून निकाल तपासा आणि चाइल्ड सुरक्षा-संबंध तुम्ही उद्देशलेले पत्ते नोंदवतात, गृहीत धरलेले नाहीत याची खात्री करा. यादी ॲप्लिकेशन सबनेट दाखवत असेल, तर बाहेरील धोरण चुकीच्या स्तरासाठी लिहिले आहे. मार्गनिर्देशन डीबग करण्यापूर्वी निवडक दुरुस्त करा, कारण मार्गनिर्देशन बरोबर दिसेल आणि काउंटर हलणार नाहीत.

फॉरवर्डिंग आणि पुनरावृत्तीचा सापळा

निवडक मार्गनिर्देशनाची जागा घेत नाहीत. A आणि B ने C आणि D मध्ये दोन्ही दिशांनी रहदारी फॉरवर्ड करणे आवश्यक आहे, म्हणजे IP फॉरवर्डिंग सुरू, बोगद्याकडे निर्देश करणारे मार्ग आणि पलीकडे असलेला परतीचा मार्ग.

बाहेरील बोगदा XFRM इंटरफेस वापरत असेल, तर मार्ग इंटरफेस निवडतात आणि वाटाघाटी झालेली धोरणे अजूनही तो काय वाहतो हे मर्यादित करतात. इंटरफेस संरक्षित व्याप्ती वाढवत नाही; तो फक्त कर्नेल पॅकेट कसे उचलते ते बदलतो.

सापळा पुनरावृत्ती आहे. B च्या बाहेरील टोकापर्यंतचा A चा मार्ग A बांधत असलेल्या बोगद्याने नाही, तर खालच्या नेटवर्कने जावा लागतो, अन्यथा एन्कॅप्सुलेशन स्वतःच्या आत प्रवास करण्याचा प्रयत्न करते आणि कनेक्शन कधीही पूर्ण होत नाही.

स्तर जोडण्यापूर्वी भाषांतर तपासा

दुसरे काही ट्यून करण्यापूर्वी A आणि B वरील कोणतेही स्रोत NAT पहा. IPsec धोरण लागू होण्यापूर्वी C चा पत्ता पुनर्लिखित करणारा नियम सहमतीचे निवडक तोडू शकतो, आणि D पलीकडे काय घेतो हेही बदलू शकतो.

दोन स्तर असल्यामुळे व्यापक मास्करेडिंग अधिक सुरक्षित होत नाही. ते दूरचा टोक कोणता पत्ता पाहतो हे लपवते, आणि बोगदा सुरू असून ॲप चालत नसताना नेमकी तीच माहिती लागते.

NAT नियम खरोखर आवश्यक असेल, तर प्रत्येक बाजू कोणत्या पत्त्याशी बोलत आहे असे मानते ते लिहा. तीच एक ओळ बोगदा की भाषांतर दोषी या वादाचा बहुतांश भाग सोडवते. वर्षभरानंतर नियम काढला जाईल तेव्हा पुढील अभियंत्याला कुठे पहावे हेही सांगते. पिंग यातील काहीही करणार नाही.

fail-closed सिद्ध करा आणि MTU तपासा

मार्ग नाहीसा होणे हे स्वतःच fail-closed धोरण नाही. दुसरे सारणी, डीफॉल्ट मार्ग किंवा धोरण नियम शांतपणे पर्याय देऊ शकतात, आणि हे कळण्याचा एकमेव मार्ग म्हणजे बाहेरील बोगदा खाली आणून ॲप्लिकेशन रहदारी काय करते ते पाहणे. अपघाताने शोधण्यापेक्षा देखभाल खिडकीत हेतुपुरस्सर करा.

तीन अवस्था तपासा: बाहेरील बोगदा खाली, आतील बोगदा खाली, आणि दोन्ही परत आल्यानंतर पुनर्प्राप्ती. प्रत्येक गेटवेवर धोरण काउंटर वापरा, कारण दोन स्थापित IKE सत्रे फक्त नियंत्रण स्तरावरील वाटाघाटी यशस्वी झाली हेच सिद्ध करतात.

दोन्ही एन्कॅप्सुलेशनसाठी बजेट ठेवा. चालणारे IKE लहान पॅकेटचा निकाल आहे, आणि दोन हेडर जोडल्यावर पूर्ण आकाराची ॲप्लिकेशन पॅकेट अजूनही अपयशी होऊ शकतात; संख्या बेरीज होतील असे गृहीत न धरता खऱ्या मार्गावर ज्ञात पेलोड आकारासह तपासा. गणित सोपे आहे, मार्ग नाही.