VGW की TGW? AWS Site-to-Site चा IPsec बोगदा कुठे संपतो

लोक विचारतात की AWS Site-to-Site VPN पॅकेटचे रक्षण कुठे थांबवते आणि एकच उत्तर अपेक्षित असते: गेटवेवर। त्या उत्तराची उपयुक्त आवृत्ती कोणते गेटवे ते सांगते, कारण व्हर्च्युअल खाजगी गेटवे आणि ट्रान्झिट गेटवे वेगळ्या जोडणी वस्तूंसह वेगळी रचना आहेत, आणि चुकीची रचना गृहीत धरणारा पुनरावलोकक उर्वरित मूल्यांकन अशा आकृतीवर उभे करतो जी अस्तित्वात नाही। खालील तीन तपासण्या क्रमाने करा। प्रत्येक एकतर सीमा निश्चित करते किंवा मागील उत्तर वेगळ्या संसाधनाबद्दल होते असे सांगते।

काहीही मूल्यांकन करण्यापूर्वी तिन्ही टोकांची नावे द्या

या मार्गाच्या एन्क्रिप्शन पुनरावलोकनासाठी तीन नाव दिलेल्या गोष्टी लागतात: ग्राहक गेटवे, IPsec संपवणारे AWS VPN लक्ष्य, आणि आंतरिक पॅकेट घेणारे अनुप्रयोग टोक। एकही कन्सोल पृष्ठ उघडण्यापूर्वी त्या त्यांच्या संसाधन ओळखकर्त्यांसह लिहून ठेवा, कारण या बिंदूनंतर सर्व काही त्या तीनपैकी एकाबद्दलचे विधान आहे।

ग्राहक गेटवे तुमचे आहे आणि त्याची संरचना तुम्हाला दिसते। AWS लक्ष्य हे व्यवस्थापित संसाधन आहे, आणि चूक ते गृहीत धरण्यात आहे: VPN कनेक्शन व्हर्च्युअल खाजगी गेटवेवर किंवा थेट ट्रान्झिट गेटवेवर जोडले जाऊ शकते, आणि एकही दुसऱ्याला अनिवार्य करत नाही। तिसरे टोक लोक वगळतात, आणि अनुप्रयोग डेटाबद्दलच्या खऱ्या प्रश्नाचे उत्तर फक्त तेच देते।

तपासणी 1: बोगदा प्रत्यक्षात कोणते गेटवे संपवते

दोन्ही रचना समर्थित आहेत आणि Site-to-Site VPN आर्किटेक्चर मार्गदर्शक त्या शेजारी शेजारी वर्णन करतो, म्हणून बऱ्याचदा वर्षभर जुनी असलेल्या आकृतीऐवजी API ला विचारा। एका कनेक्शनवरील फक्त-वाचन चौकशी VPN लक्ष्य क्षेत्रे परत करते:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

भेदक TransitGatewayId आहे, VpnGatewayId नाही। ज्या कनेक्शनमध्ये TransitGatewayId रिकामे आहे ते स्वतंत्र व्हर्च्युअल खाजगी गेटवेवर संपते, तर ते क्षेत्र सेट असलेले कनेक्शन ट्रान्झिट गेटवेच्या VPN जोडणीवर संपते, आणि त्या बाबतीत VpnGatewayId अजूनही भरलेले असू शकते कारण ते जोडणीच्या आधारभूत गेटवेचे नाव देऊ शकते। प्रथम TGW क्षेत्र वाचा, नंतर जोडणीचा प्रकार क्षेत्राच्या नावावरून नाही तर जोडणी यादीतून निश्चित करा, कारण त्या ट्रान्झिट गेटवेवरील VPC जोडणी VPN जोडणी नाही। जोडलेल्या VPC मध्ये गंतव्य इन्स्टन्स सापडणे पॅकेट कोणत्या VPN जोडणीने नेले याबद्दल काहीही सांगत नाही।

तिथे असताना बोगदेही तपासा। कनेक्शन अतिरिक्ततेसाठी दोन IPsec बोगदे वाहून नेते, आणि ज्याचा दुसरा बोगदा कधीही उभा राहिला नाही असे कनेक्शन एन्क्रिप्शन सीमेवर काहीही न बदलता उपलब्धतेसाठी खरा शोध ठरतो:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

तपासणी 2: आंतरिक पॅकेट अजूनही काय वाहते

IPsec संपल्यानंतर AWS डीकॅप्स्युलेटेड पॅकेटला त्याला जुळणाऱ्या मार्गाने पुढे पाठवते। त्या बिंदूपासून रहदारी सामान्य VPC रहदारी आहे, आणि VPN चे संरक्षण संपले आहे। हे सेवेतील पोकळी नाही; हा सीमेचा अर्थ आहे, आणि चेकलिस्टमधील मुद्दा ते स्पष्टपणे सांगणे आहे, "VPN एन्क्रिप्टेड आहे" ला "डेटा सुरुवातीपासून शेवटपर्यंत एन्क्रिप्टेड आहे" च्या जागी उभे राहू न देणे।

आता आत काय होते ते पाहा। आंतरिक पॅकेट साध्या मजकुरातील अनुप्रयोग प्रोटोकॉल असल्यास, दुसरे काही ते एन्क्रिप्ट करेपर्यंत खालच्या बाजूला काहीही गोपनीयता जोडत नाही। आंतरिक पॅकेट आधीच TLS सत्र वाहत असल्यास, बाहेरील IPsec काढून टाकल्याने त्या सत्रात काहीही बदलत नाही: ते स्वतःच्या टोकापर्यंत संरक्षित राहते, ते टोक कुठेही असो।

नेहमीचा अति-दुरुस्ती म्हणजे गेटवेच्या मागील सर्व काही उघडे आहे असा निष्कर्ष काढणे। तसे नाही। सेवा वाहतूक, साठवण एन्क्रिप्शन आणि अनुप्रयोग TLS या वेगळ्या अटींसह वेगळ्या यंत्रणा आहेत, आणि प्रत्येकाचे मूल्यांकन VPN च्या आकारावरून अनुमान काढण्याऐवजी त्याच्या स्वतःच्या अटींवर करायला हवे। ACCEPT दाखवणारी प्रवाह नोंद नोंदवते की मार्गनिर्देशन चालले आणि गोपनीयतेबद्दल काहीही सांगत नाही, आणि ही चेकलिस्ट तीच चूक टाळण्यासाठी आहे।

तपासणी 3: गेटवेच्या मागे TLS कोणते संपवते

पत्त्याचा नाही, श्रोत्याचा मागोवा घ्या। लोड बॅलन्सर किंवा प्रॉक्सी TLS संपवत असेल, तर तुमच्या क्लायंटकडील कनेक्शन तिथेच संपते, आणि प्रॉक्सी बॅकएंडशी दुसरे कनेक्शन उघडते जे साधा मजकूर किंवा वेगळ्या विश्वास साखळीचे TLS असू शकते। खाजगी IP पत्ता आणि जुळणारा मार्ग त्या दुसऱ्या कनेक्शनबद्दलचा पुरावा नाही।

तुम्हाला खरोखर महत्त्वाचे असलेले टोक VPC च्या आतून तपासा, अनुप्रयोग वापरत असलेल्या नावाने, एकदा सोडवलेल्या IP ने नाही:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

विनंती जाते त्या प्रत्येक हॉपसाठी हे पुन्हा करा। उत्तर क्लायंटकडील नाव आणि बॅकएंडच्या नावात वेगळे असेल, तर VPN ने कधीही झाकले नाही तोच विभाग तुम्ही शोधला आहे, आणि तोच लिहून ठेवण्याजोगा शोध आहे।

निकाल निर्णय म्हणून नाही, विभाग म्हणून नोंदवा

या चेकलिस्टचा निकाल प्रत्येक विभागासाठी एक ओळ असलेला छोटा तक्ता आहे: ग्राहक गेटवेपासून AWS VPN लक्ष्यापर्यंत, गेटवेपासून कार्यभारापर्यंत, कार्यभारापासून डेटा साठवणीपर्यंत, आणि मधल्या कोणत्याही प्रॉक्सी हॉपपर्यंत। प्रत्येक ओळ सांगते की त्याचे रक्षण काय करते आणि ते संरक्षण कशावर अवलंबून आहे। यंत्रणा आणि टोक नसलेले "एन्क्रिप्टेड" ही ओळ नाही।

नंतर मूळ आवश्यकतेचे उत्तर ती ज्या शब्दांत विचारली होती त्याच शब्दांत द्या। आवश्यकता अशी असेल की कार्यभार तो मिळेपर्यंत डेटा गोपनीय राहावा, तर VPN फक्त पहिला विभाग पूर्ण करतो, आणि उर्वरित ओळींना अनुप्रयोग वाहतूक, सेवा TLS किंवा साठवण एन्क्रिप्शन स्वतंत्रपणे संरचित आणि सत्यापित करावे लागते।

कनेक्शन ओळखकर्ते, बोगद्यांची स्थिती आणि प्रमाणपत्राचे विषय नोंदीत ठेवा। सहा महिन्यांनंतर कोणी रचनेकडे परत आल्यास ते तीन कलाकृती आकृतीवरून वाद पुन्हा सुरू न करता मिनिटांत सीमेच्या प्रश्नाचे उत्तर देतात।