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. अगर AWS को DPD टाइमआउट के बाद बातचीत फिर से शुरू करनी है, तो उस घटना के लिए अलग से 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 शुरुआत का दस्तावेज़ कंसोल के संकेतों की तुलना में पता, पहचान और रीट्राई की आवश्यकताओं को अधिक विस्तार से बताता है।