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 सुरुवातीचे दस्तऐवज कन्सोलच्या इशाऱ्यांपेक्षा पत्ता, ओळख आणि पुन्हा प्रयत्नांच्या आवश्यकता अधिक तपशिलाने समाविष्ट करते.