strongSwan कडून AWS Site-to-Site कडे: Child SA काहीही का निवडत नाही

कन्सोल up दाखवते, strongSwan स्थापित IKE असोसिएशनची नोंद करते, आणि पॅकेट तरीही पोहोचत नाहीत। पुढे तुलना करायची गोष्ट प्री-शेअर्ड की नाही, तर प्रत्येक बाजू बोगदा ज्यांचे रक्षण करतो असे मानते त्या प्रीफिक्सची जोडी आहे। खालील तपासण्या क्रमाने करा, कारण पहिल्या दोन बोगदा तुमचा रहदारी अजिबात वाहू शकतो का हे ठरवतात.

AWS ची नावे strongSwan च्या संज्ञांमध्ये भाषांतरित करा

AWS ग्राहकाच्या बाजूने कनेक्शनचे वर्णन करते: ग्राहक गेटवेचा पत्ता आणि स्थानिक CIDR तुमचे आहेत, आणि दूरचा CIDR VPC चा आहे। strongSwan दोन्ही टोकांना left आणि right म्हणते, तुमचा प्रीफिक्स leftsubnet मध्ये आणि VPC चा प्रीफिक्स rightsubnet मध्ये असतो। एक जोडी उलटल्यास चुकीच्या रहदारीची बोलणी करून ती निवडणारा बोगदा तयार होतो.

AWS कनेक्शनसाठी तयार करते ते कॉन्फिगरेशन डाउनलोड करा आणि बोगद्याचे पत्ते व प्रीफिक्सांसह तेच त्या कनेक्शनचे संदर्भ माना। तयार करताना दोन्ही CIDR क्षेत्रे रिकामी सोडल्यास सेवा प्रत्येक बाजूला 0.0.0.0/0 डीफॉल्ट वापरते। अरुंद प्रीफिक्सने बसवलेला राउटर मग त्याच्याशी कधीही जुळणार नाही, म्हणून क्षेत्रे भरा किंवा निवडक जाणीवपूर्वक रुंद करा.

इथली विसंगती राउटिंग अयशस्वी वाटते आणि ती नाही.

AWS प्रत्यक्षात जो पत्ता पाहते तो निश्चित करा

NAT मागील राउटर समोरच्या बाजूने कधीही न जाणलेल्या इंटरफेसवरून IKE पाठवू शकतो। AWS मध्ये नोंदवलेला गेटवे पत्ता AWS नेटवर्कवर पाहतो तोच असला पाहिजे, आणि राउटरने आपल्या डीफॉल्ट मार्गाने जाण्याऐवजी त्याच स्थानिक पत्त्यावर निश्चित व्हावे.

conn %default
    local_addrs = 203.0.113.10

strongSwan मध्ये local_addrs IKE साठी स्रोत पत्ता निवडते, आणि जुन्या OpenSwan कॉन्फिगरेशन्स तीच कल्पना left अशी लिहितात। तो सार्वजनिक पत्ता असलेल्या इंटरफेसकडे वळवा, नंतर NAT उपकरणावरच UDP 500 आणि 4500 त्या होस्टपर्यंत पोहोचतात का ते तपासा, कारण आधीच्या राउटरपासून राहिलेला नियम त्यांना शांतपणे टाकून देतो। बरोबर निवडक जोडी चुकीच्या स्रोत पत्त्यासह तरीही अयशस्वी होते, आणि लॉग दोष प्रस्तावावर टाकेल। हाच गोंधळ स्रोत पत्त्याला स्वतंत्र तपासणी का हवी याचे कारण आहे.

फॉरवर्डिंग नियम गृहीत धरण्याऐवजी त्याची खात्री करा, कारण आधीच्या राउटरसाठी बरोबर असलेला नियम अनेकदा राहतो.

फेज 1 आणि फेज 2 स्वतंत्रपणे हाताळा

AWS IKE आणि ESP पर्याय वेगळ्या याद्या म्हणून दाखवते। दोन्ही बाजू स्वीकारतात तो IKE संच ESP प्रस्तावाबद्दल काहीच सांगत नाही, कारण दोन्ही याद्या स्वतंत्र आहेत। दोन्ही तयार कॉन्फिगरेशनमधून वाचा आणि एकामागून एक तुलना करा.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

वाक्यरचना अंमलबजावणींमध्ये जात नाही। OpenSwan मध्ये चालणारी जोडी, उदाहरणार्थ phase2alg=aes_gcm सोबत ike=aes256-sha1;modp1024, strongSwan च्या esp= आणि ike= स्वरूपात भाषांतरित करावी लागते, आणि अल्गोरिदमची नावे वेगळी असतात। GCM एन्क्रिप्ट करतानाच प्रमाणीकरण करते, म्हणून SHA सोबत जोडलेल्या CBC संचाप्रमाणे त्याला वेगळे अखंडता रूपांतरण लागत नाही। एका डीमनमधून दुसऱ्यात भाषांतराशिवाय चिकटवलेली फेज 2 ओळ निवडक विसंगतीसारखे वाचले जाणारे नाकारणे निर्माण करते.

बोगदा निर्देशक नाही, चाइल्ड असोसिएशन तपासा

कनेक्शन लोड होते पण चाइल्ड असोसिएशन उठत नसेल, तर प्रस्ताव किंवा निवडक नाकारले गेले आहेत। चाइल्ड उठत असेल आणि त्याचे निवडक तुमचे प्रीफिक्स वगळत असतील, तर पॅकेट बोगद्यापर्यंत पोहोचण्यापूर्वी गाळले जातात। कन्सोलचा निर्देशक फक्त IKE स्तर व्यापतो, म्हणून दोनपैकी काय घडले ते सांगू शकत नाही.

ipsec statusall

चाइल्ड सुरक्षा असोसिएशन शोधा आणि त्याच्या शेजारी छापलेले रहदारी निवडक वाचा, नंतर त्यांची तयार कॉन्फिगरेशनच्या प्रीफिक्सांशी तुलना करा.

स्थानिक प्रीफिक्समधील होस्टवरून VPC प्रीफिक्समधील होस्टपर्यंत चाचणी करा आणि परतीचा मार्ग तसेच AWS बाजूचा कोणताही सुरक्षा गट किंवा नेटवर्क ACL तपासा। बरोबर निवडक पॅकेट नंतर टाकून दिल्यापासून संरक्षण करत नाहीत.

निवडक जुळल्यानंतरही अयशस्वी झाल्यास

दोन्ही बाजूंचा मार्ग बोगद्याकडे जातो याची खात्री करा, नंतर NAT उपकरण धोरण अपेक्षित नसलेल्या पद्धतीने रहदारी पुन्हा लिहीत नाही याची खात्री करा। धोरणाधारित बोगदा पॅकेटचे पत्ते जुळवतो, म्हणून धोरण निर्णयानंतर लागू केलेले भाषांतर निकाल बदलते.

दुसरा प्रस्ताव बदलण्यापूर्वी प्रत्येक बाजूला एक येणारे आणि एक जाणारे पॅकेट लॉग करा.

तिकिटात निवडक, फेज 1 व फेज 2 चे प्रस्ताव आणि स्रोत पत्ता नोंदवा। ही चार मूल्ये कॉलशिवाय बहुतेक site-to-site अयशस्वी समजावून सांगतात.