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 या संग्रहण एन्क्रिप्शन अलग से कॉन्फ़िगर और सत्यापित करना होगा।

कनेक्शन पहचानकर्ता, टनल की स्थितियाँ और प्रमाणपत्र विषय रिकॉर्ड में रखिए। जब कोई छह महीने बाद डिज़ाइन पर लौटता है, तो ये तीन कलाकृतियाँ मिनटों में सीमा का सवाल हल कर देती हैं, बजाय डायग्राम से बहस फिर शुरू करने के।