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 वा भण्डारण इन्क्रिप्शन छुट्टै कन्फिगर र प्रमाणित गर्नुपर्छ।

जडान पहिचानकर्ता, सुरुङको अवस्था र प्रमाणपत्रका विषय अभिलेखमा राख्नुहोस्। छ महिनापछि कसैले डिजाइनमा फर्कँदा ती तीन कलाकृतिले रेखाचित्रबाट बहस फेरि सुरु गर्नुको सट्टा मिनेटमै सीमाको प्रश्नको उत्तर दिन्छन्।