AWS Client VPN पर रुक-रुक कर पहुँच: हर जुड़े सबनेट का ऑडिट करें

एक उपयोगकर्ता कनेक्ट होता है, आंतरिक ऐप खोलता है और उत्तर पाता है; उसी एंडपॉइंट पर एक सहकर्मी को उसी Wi-Fi पर समान लैपटॉप से समय-समाप्ति मिलती है। यह पैटर्न client VPN एंडपॉइंट का हस्ताक्षर है जिसमें एक से अधिक जुड़े सबनेट हैं, जहाँ मार्ग समान नहीं हैं। मैं इसे कंसोल से बाहर की ओर देखता हूँ, क्योंकि दो टैब तय करते हैं कि बाकी जाँच करने लायक है या नहीं। क्लाइंट कॉन्फ़िगरेशन में कुछ भी इसे समझाता नहीं है।

एंडपॉइंट से शुरू करें और जुड़ावों की सूची बनाएँ

VPC कंसोल में Client VPN endpoints खोलें, एंडपॉइंट चुनें और Associations टैब पढ़ें। हर जुड़ाव किसी उपलब्धता क्षेत्र में एक सबनेट है, और कनेक्शन बनते समय क्लाइंट उसी पर उतरता है जिसे सेवा चुनती है। सबनेट ID और वह रूट टेबल नोट करें जिसका हर एक वास्तव में उपयोग करता है, क्योंकि यही दो सूचियाँ वह तुलना हैं जो आप करने वाले हैं।

अगर एंडपॉइंट केवल एक जुड़ाव दिखाता है, तो यह सिद्धांत गलत है और क्लाइंट बेहतर संदिग्ध है।

एंडपॉइंट रूट टेबल की हर जुड़ाव से तुलना करें

उसी एंडपॉइंट पर Route table टैब खोलें। वहाँ हर गंतव्य CIDR का एक लक्ष्य है, और client VPN में लक्ष्य गेटवे नहीं बल्कि जुड़ाव है। AWS हर जुड़े सबनेट के लिए गंतव्य प्रविष्टि मांगता है, इसलिए केवल एक को लक्षित करने वाला रूट पहुँच को इस पर निर्भर कर देता है कि सत्र कहाँ उतरा। जिस गंतव्य की आपको वास्तव में आवश्यकता है उसे जाँचें, फिर उसका प्राधिकरण नियम जाँचें, क्योंकि रूट मार्ग देता है और नियम तय करता है कि कौन इसका उपयोग कर सकता है।

दोनों परतों को तालिका में लाने के बाद खराबी को छोड़ना कठिन है।

अधिकांश टिकटों में दूसरी पंक्ति ही पूरा बग है। एंडपॉइंट रूट मौजूद है, इसलिए कोई आगे नहीं देखता, और पैकेट एक हॉप बाद VPC के भीतर मर जाता है।

हर सबनेट का उसके प्रभावी रूट टेबल तक पीछा करें

जिस सबनेट का कोई स्पष्ट रूट टेबल जुड़ाव नहीं है वह VPC की मुख्य टेबल विरासत में पाता है। वह टेबल पढ़ें जो वास्तव में प्रभावी है, वह नहीं जिसका नाम सही लगता है, और पंक्ति के लेबल की जगह गंतव्य और लक्ष्य की तुलना करें।

AWS की रुक-रुक कर पहुँच मार्गदर्शिका इसे जुड़ावों में रूट कवरेज के रूप में प्रस्तुत करती है, जो सही मॉडल है। एंडपॉइंट पैकेट को एक सबनेट तक पहुँचाता है, और उस सबनेट की टेबल को अभी भी जानना होता है कि एप्लिकेशन नेटवर्क कहाँ है।

जिस टेबल का यह स्वामित्व है उसमें गायब पंक्ति ठीक करें। काम करने वाले सबनेट से पूरी रूट टेबल कॉपी करने से इंटरनेट, उपकरण और अलगाव के वे विकल्प भी कॉपी होते हैं जो कभी इसके लिए नहीं सोचे गए थे, और यह अदला-बदली आमतौर पर उसी रुकावट से बदतर होती है जिससे आपने शुरू किया।

प्राधिकरण नियम जाँचें, फिर वापसी का मार्ग

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

वापसी का मार्ग भी उतना ही ध्यान देने योग्य है। peering कनेक्शन को एप्लिकेशन VPC में क्लाइंट CIDR की ओर वापस जाता रूट, दोनों सिरों पर ट्रैफ़िक की अनुमति देने वाले सुरक्षा समूह नियम, और उसे गिराते नहीं नेटवर्क ACL चाहिए। एकतरफ़ा पहुँच, जहाँ ping काम करता है और TCP हैंडशेक नहीं, आमतौर पर VPN नहीं बल्कि ACL या सुरक्षा समूह की ओर इशारा करता है।

एंडपॉइंट के अपने सुरक्षा समूह जुड़ाव के इलास्टिक नेटवर्क इंटरफ़ेस पर बैठते हैं, इसलिए क्लाइंट CIDR से एप्लिकेशन पोर्ट की अनुमति देने वाला नियम केवल इंस्टेंस के साथ नहीं, जुड़ाव के साथ जोड़ना होगा।

एक भाग्यशाली अनुरोध से नहीं, दोबारा कनेक्ट करके सत्यापित करें

split tunnel के साथ, कनेक्शन स्थापित होने पर एंडपॉइंट रूट भेजे जाते हैं, इसलिए बदला हुआ रूट सेट कनेक्टेड रहने वाले क्लाइंट तक कभी नहीं पहुँचता। समर्थित क्लाइंट से डिस्कनेक्ट करें और फिर कनेक्ट करें, फिर पुष्टि करें कि नए रूट मशीन पर मौजूद हैं।

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