strongSwan से AWS Site-to-Site: Child SA कुछ भी क्यों नहीं चुनता

IKE टनल चालू रह सकती है जबकि चाइल्ड एसोसिएशन आपके सबनेट को बाहर रखता है। पहले AWS के लोकल और रिमोट CIDR की तुलना leftsubnet और rightsubnet से करें।

कंसोल स्थिति 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 विफलताएँ समझा देते हैं।

संबंधित लेख