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 असफलता व्याख्या गर्छन्।