peered VPC तक पहुँचने के लिए AWS Client VPN या bastion

एक Client VPN endpoint उस VPC तक पहुँच सकता है जो उसके संबद्ध VPC के साथ peered है, और इसे वैध बनाने के लिए आपको bastion की ज़रूरत नहीं है। जो चुनाव करने लायक है वह यह है कि ट्रैफ़िक कहाँ हाथ बदलता है: एक endpoint रूट जो association सबनेट में उतरता है और peering कनेक्शन पार करता है, या peered VPC में एक host जो सत्र समाप्त करता है। दोनों रास्ते काम करते हैं और अलग-अलग जगह विफल होते हैं, इसलिए निर्णय स्वामित्व और ऑडिट के बारे में है, इस बारे में नहीं कि AWS क्या अनुमति देता है। यहाँ है कि मैं उनके बीच कैसे चुनता हूँ, और वे चार प्रविष्टियाँ जो routed रास्ते को काम कराती हैं।

दो रास्ते, एक endpoint, अलग मालिक

routed रास्ते पर क्लाइंट ट्रैफ़िक endpoint तक पहुँचता है, association सबनेट में Client VPN नेटवर्क इंटरफ़ेस के पते में अनूदित होता है, और A से B तक peering कनेक्शन के ज़रिए उस सबनेट से निकलता है। VPC B कोई VPN सत्र समाप्त नहीं करता; वह VPC A से सामान्य ट्रैफ़िक देखता है, इसीलिए उसका रिटर्न रूट VPC A की ओर इंगित करता है, क्लाइंट पूल की ओर नहीं।

bastion रास्ते पर क्लाइंट पहले एक host तक पहुँचता है। A में bastion अंतिम हॉप को अब भी peering कनेक्शन पार करने देता है, इसलिए आप peering का काम बनाए रखते हैं और एक सत्र जोड़ते हैं। B में bastion को भी क्लाइंट से रास्ता चाहिए, और जब वह रास्ता वही endpoint रूट हो, तो आपके पास routed डिज़ाइन के साथ एक हॉप अधिक है। bastion केवल तब काम घटाता है जब वह पहले से मौजूद हो, पहले से अनुमोदित हो, और उसके पीछे की चीज़ को नेटवर्क सीमा के बजाय सत्र सीमा चाहिए।

चार प्रविष्टियाँ routed रास्ते को काम कराती हैं

AWS इस परिदृश्य को Client VPN how-it-works पृष्ठ पर दस्तावेज़ित करता है, और व्यवहार में यह दो या तीन टीमों के स्वामित्व वाली चार प्रविष्टियों पर आता है। रेंजें उदाहरण हैं; peered रेंज अद्वितीय होनी चाहिए और रिटर्न रेंज आपकी योजना से मेल खानी चाहिए।

रूट और अनुमति अलग नियंत्रण हैं। मेल खाते प्राधिकरण नियम के बिना सही endpoint रूट क्लाइंट को कुछ नहीं देता; ऐसे गंतव्य के लिए प्राधिकरण नियम जिसे endpoint रूट नहीं कर सकता, उसे काला छेद देता है। दोनों को एक ही रेंज बतानी चाहिए।

endpoint रूट endpoint के अपने VPC के एक सबनेट की ओर इंगित करता है, कभी peering कनेक्शन की ओर नहीं। VPC रूट तालिकाएँ peering कनेक्शन की ओर इंगित करती हैं, कभी instance या इंटरफ़ेस की ओर नहीं। दोनों के बीच मान की प्रतिलिपि बिना शिकायत सहेजी जाती है और कुछ रूट नहीं करती।

चूँकि association सबनेट क्लाइंट के स्रोत का अनुवाद करता है, B को क्लाइंट पूल की ओर नहीं, VPC A की ओर वापस रूट करना चाहिए। peering कनेक्शन पर क्लाइंट रेंज भेजना सममित दिखता है, समीक्षा पार करता है और चुपचाप विफल होता है क्योंकि B कभी क्लाइंट स्रोत वाला पैकेट नहीं देखता।

सुरक्षा समूह और अनुमति का अंतिम मीटर

रूटिंग पैकेट B में पहुँचाती है; B अब भी निर्णय लेता है। उसी क्षेत्र में सक्रिय peering कनेक्शन के लिए, B में एक सुरक्षा समूह Client VPN association पर लागू समूह का संदर्भ दे सकता है, जो नियम को संकीर्ण रखता है और पता परिवर्तनों में टिकता है। जहाँ समूह संदर्भ व्यवहार्य न हो, वहाँ 0.0.0.0/0 तक चौड़ा करने के बजाय association सबनेट रेंज को स्पष्ट रूप से अनुमति दें, क्योंकि यह रूटिंग त्रुटि को अस्पष्ट टाइमआउट में बदल देता है।

फिर देखें कि रूटिंग कभी किसे नहीं छूती: दोनों सबनेट पर नेटवर्क ACL, एप्लिकेशन की allow-list या टोकन ऑडियंस, और DNS। peering निजी होस्टेड ज़ोन की प्रतिलिपि नहीं करता, इसलिए लैपटॉप ऐसे पते तक काम करने वाला रूट रख सकता है जिसे वह हल नहीं कर सकता, और peering कनेक्शन प्रमाणपत्र में कोई भरोसा नहीं जोड़ता। endpoint को ऐसे resolver की ओर इंगित करें जो B के लिए उत्तर दे, फिर पुष्टि करें कि निजी नाम और प्रमाणपत्र मेल खाते हैं।

कब bastion ईमानदार उत्तर है

मैं जानबूझकर bastion चुनने के लिए तीन ट्रिगर रखता हूँ। peered VPC ऐसी टीम का है जो आपकी रेंज के लिए रिटर्न रूट नहीं जोड़ेगी या समूह संदर्भ स्वीकार नहीं करेगी। पहुँच प्रति सत्र अनुमोदित या दर्ज होनी चाहिए और एप्लिकेशन इसे स्वयं नहीं उठा सकता। या अंतिम हॉप को B के भीतर ही रहना है क्योंकि सेवा केवल वहीं हल होती है और उसकी TLS पहचान आंतरिक नाम से पिन है।

इनमें से कोई भी इस तथ्य के चारों ओर रास्ता नहीं है कि peering ट्रांज़िटिव नहीं है। गैर-ट्रांज़िटिविटी सीमित करती है कि B के संसाधन क्या कर सकते हैं: वे A का उपयोग तीसरे VPC तक ट्रांज़िट के रूप में नहीं कर सकते जिसके साथ A peered है। इसका अर्थ कभी यह नहीं था कि VPN उपयोगकर्ता सीधे peered VPC तक नहीं पहुँच सकता, और उस गलत पठन को टालने के लिए बनाया गया bastion बिना कारण patch करने वाला host है।

उलटी गलती समय के साथ अधिक महँगी है: हर टीम को उस एकमात्र bastion से गुज़ारें जो पहले से मौजूद है, फिर पाएँ कि उसका सुरक्षा समूह, रूट तालिका और patch विंडो ही उत्पादन निर्भरता हैं। लिखें कि host किस ट्रिगर की सेवा करता है, और ट्रिगर जाने पर उसे सेवानिवृत्त करें।

Transit Gateway और कई association गणना बदलते हैं

यदि endpoint सबनेट के बजाय सीधे Transit Gateway से जुड़ा है, तो मॉडल बदल जाता है: क्लाइंट अब association सबनेट में इंटरफ़ेस पते में अनूदित नहीं होते, और gateway रूट तालिकाओं को क्लाइंट रेंज के साथ वह जोड़ भी ले जाना होता है जो peered VPC तक ले जाता है। यह पैमाने पर अधिक साफ़ है, पर काम चार प्रविष्टियों से gateway रूट तालिकाओं में चला जाता है।

कई association जाँचों को गुणा करते हैं। endpoint रूट endpoint का है, फिर भी हर association सबनेट को वास्तविक peering next hop वाली रूट तालिका चाहिए। एक association से सत्र सफल हो सकता है जबकि दूसरे के पास रिटर्न रास्ता न हो, इसलिए हर एक को जाँचें।

वह सत्यापन क्रम जो भंग जल्दी खोजता है

इन्हें क्रम से चलाएँ; हर चरण पास हो सकता है जबकि अगला विफल हो, और क्लाइंट टाइमआउट लगभग कभी नहीं बताता कि कौन टूटा।

1. क्लाइंट से एप्लिकेशन का नाम हल करें और जाँचें कि पता peered रेंज के भीतर है।
2. कनेक्ट करें, फिर जिस association ने सत्र समाप्त किया उसके लिए endpoint कनेक्शन लॉग पढ़ें।
3. उस association सबनेट पर पुष्टि करें कि रूट तालिका peered रेंज को सक्रिय peering कनेक्शन की ओर इंगित करती है।
4. B के संसाधन सबनेट पर इंटरफ़ेस रेंज के लिए रिटर्न प्रविष्टि और मेल खाते समूह नियमों की पुष्टि करें।
5. एक अनुमत कार्रवाई और एक ऐसे संसाधन का परीक्षण करें जो अगम्य रहना चाहिए; दूसरा डिबगिंग के अवशेष पकड़ता है।
6. किसी भी split-tunnel रूट परिवर्तन के बाद फिर से कनेक्ट करें, क्योंकि चल रहा टनल नया रूट सेट नहीं लेगा।

दो लक्षण याद रखने योग्य हैं। B तक बिना उत्तर पहुँचने वाला SYN लगभग हमेशा गायब रिटर्न रूट होता है। पूरा होकर फिर रीसेट होने वाला कनेक्शन आमतौर पर समूह, ACL या एप्लिकेशन होता है। कोई भी endpoint लॉग में कारण के रूप में नहीं दिखता, इसलिए चार प्रविष्टियाँ हर एक के बगल में मालिक के साथ रखें।

यदि तीनों में से कोई ट्रिगर लागू नहीं होता, तो routed रास्ता पूरा करें और वे चार प्रविष्टियाँ दर्ज करें। यदि एक लागू होता है, तो bastion को केवल उसी सीमा के लिए रखें और उन सेवाओं के लिए endpoint रूट छोड़ दें जिन्हें सामने सत्र की ज़रूरत नहीं है।