AWS लाई Site-to-Site VPN सुरुङ सुरु गर्न कसरी लगाउने
Startup action र DPD timeout action ले फरक प्रश्नको जवाफ दिन्छन्। AWS लाई सुरु गराउने कुरा सेट गर्नुहोस्, त्यसपछि पीयरको ठेगाना र एपको मार्ग जाँच्नुहोस्।
पूर्वनिर्धारित रूपमा, AWS Site-to-Site VPN ले customer gateway ले वार्ता सुरु गर्ने प्रतीक्षा गर्छ। त्यो पूर्वनिर्धारित एउटा सेटिङ हो, कानुन होइन, र सेटिङको नाम Startup action हो। त्यसतर्फ जानु अघि, सधैं मिसिने दुई प्रश्न छुट्याउनुहोस्: सुरुङ कसले बनाउँछ, र तपाईंलाई महत्त्वपूर्ण प्याकेटहरूको यसबाट जाने मार्ग छ कि छैन। पहिलो मात्र सुरुङका विकल्पहरूमा हुन्छ।
सुरुवाती कार्यलाई DPD टाइमआउट कार्यबाट छुट्याउनुहोस्
प्रत्येक सुरुङका लागि दुई विकल्पले दुई फरक घटना नियन्त्रण गर्छन्, र एउटा सेट गर्दा अर्कोबारे केही भनिँदैन।
| Event | Option | Useful values |
|---|---|---|
| A new or modified VPN connection needs a tunnel | Startup action | add waits for the peer; start asks AWS to initiate |
| Dead peer detection times out | DPD timeout action | clear ends the session, restart reinitiates, none does nothing |
AWS ले नयाँ वा परिवर्तित सुरुङ उठाउनुपर्ने भए, छान्नुहोस् start. DPD टाइमआउटपछि AWS ले वार्ता पनि पुनः सुरु गर्नुपर्ने भए, त्यो घटनाका लागि अलग्गै restart कन्फिगर गर्नुहोस्। दुवैमध्ये कुनै विकल्प एपको पुनः प्रयास नीति होइन, र कुनै पनि कुञ्जी परिवर्तनको अन्तराल होइन: DPD ले पीयर जीवित छ कि छैन जाँच्छ, जबकि कुञ्जी परिवर्तनले सक्रिय सुरुङमा security associations फेर्छ।
सुरुङले अझै up देखाइरहेको बेला टाइमआउट हुने एपलाई डेटा-मार्गको समस्या हुन्छ। DPD टाइमर छोटो पार्नाले त्यो सुधार्दैन, र पछि बुझाउनुपर्ने हल्ला थप्न सक्छ।
AWS सँग वार्ता पठाउने ठाउँ छ कि छैन जाँच्नुहोस्
AWS पक्षबाट सुरु गर्नु IKEv2 मा मात्र सम्भव छ, र प्रस्ताव कहाँ पठाउने भनी जान्न AWS लाई customer gateway को सार्वजनिक ठेगाना चाहिन्छ। सबैभन्दा दुखाउने अवस्था ठेगाना बिना बनाइएको प्रमाणपत्र-प्रमाणित customer gateway स्रोत हो: AWS को कागजातले ठेगानासहित नयाँ customer gateway स्रोत बनाई त्यसपछि VPN जडान त्यसतर्फ फर्काउने वर्णन गर्छ।
प्रमाणपत्रले पीयर को हो भनी प्रमाणित गर्छ। यसले AWS लाई पीयर कहाँ छ भनी बताउँदैन, र यी दुई फरक आवश्यकता हुन्। त्यसैले समाधान नयाँ प्रमाणपत्र होइन, नयाँ customer gateway स्रोत हो। प्रमाणपत्र बदल्दा AWS सँग त्यही हराएको गन्तव्य रहन्छ।
यदि customer gateway NAT पछाडि छ, AWS लाई कन्फिगर गरिएको responder identity पनि चाहिन्छ, IDr, पीयरको पहिचान यन्त्रले अपेक्षा गरेकोसँग मिल्नका लागि। भर्खरै बदलेको विकल्पलाई दोष दिनु अघि त्यो मान र IKE ट्राफिक जान दिने फायरवाल मार्ग पुष्टि गर्नुहोस्। start छान्दा पुग्न नसकिने वा गलत पहिचान भएको पीयरलाई प्रस्ताव स्वीकार गर्न बाध्य पार्न सकिँदैन।
परिवर्तन एउटा सुरुङमा लागू गर्नुहोस् र अवरोध अपेक्षा गर्नुहोस्
VPN जडानमा स्वतन्त्र विकल्प भएका दुई सुरुङ हुन्छन्, त्यसैले बाहिरी ठेगानाबाट कुन सम्पादन गर्दै हुनुहुन्छ पुष्टि गर्नुहोस्। AWS ले एक पटकमा एउटा मात्र सुरुङ बदल्न दिन्छ, र छानिएको सुरुङमार्फत जडान केही मिनेटका लागि टुट्न सक्छ।
- Site-to-Site VPN जडान छान्नुहोस् र Modify VPN tunnel options खोल्नुहोस्।
- बाहिरी IP ठेगानाबाट सुरुङ छान्नुहोस् र त्यसको IKE संस्करण तथा customer gateway स्रोत पुष्टि गर्नुहोस्।
- तपाईंले साँच्चै चाहेका सुरुवात र DPD कार्यहरू सेट गर्नुहोस्, त्यसपछि आफ्नो नियन्त्रणको अवधिमा सुरक्षित गर्नुहोस्।
- परिवर्तित सुरुङ स्थापित हुन्छ भनी पुष्टि गर्नुहोस्, र अर्को परिवर्तनअघि अर्को सुरुङ र राउटिङ जाँच्नुहोस्।
मर्मतअघि एउटा व्यवहार ध्यान दिन योग्य छ। AWS सुरुवात सक्षम हुँदा कुनै टाइमआउट हुँदैन: सुरुङ नउठेसम्म AWS प्रयास गरिरहन्छ, र customer gateway ले delete-SA सन्देश पठाउँदा फेरि सुरु गर्छ। यदि पीयर जानाजान बन्द गर्नुभयो भने, AWS ढकढक गरिरहन्छ, र पीयरका लगहरूले त्यो देखाउनेछन्।
सुरुङको अवस्था मात्र होइन, एपको मार्ग प्रमाणित गर्नुहोस्
up देखाउने सुरुङ काम गर्ने अनुरोधसँग बराबर हुँदैन। VPC मा जोडिएको Lambda फंक्शनलाई अझै ग्राहकको प्रिफिक्ससम्म subnet मार्ग, ट्राफिक अनुमति दिने security group र network ACL नियम, सही ठेगाना फर्काउने नाम-समाधान, र ग्राहकको पक्षमा फर्कने मार्गचाहिन्छ।
एपको सन्दर्भबाट एक पटक वास्तविक अनुरोधसँग परीक्षण गर्नुहोस्, असफल भए flow logs पढ्नुहोस्। AWS सुरुवात बन्द हुँदा र निष्क्रिय सुरुङलाई टिकिरहन प्याकेट चाहिँदा keepalive ट्राफिक वैध विकल्प हो, तर त्यो तपाईंले नाम दिन सक्ने अनुगमन निर्णय हुनुपर्छ, फंक्शनमा जोडिएको अस्पष्ट ping लूप होइन।
पहिले सुरुङ कसले बनाउँछ भन्ने छान्नुहोस्, त्यसपछि बाँकी असफलताको निदान त्यसको आफ्नै तहमा गर्नुहोस्। AWS को सुरुवातसम्बन्धी कागजात ले कन्सोलका संकेतभन्दा ठेगाना, पहिचान र पुनः प्रयासका आवश्यकताहरू बढी विस्तारमा समेट्छ।