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 मा, जडान स्थापना हुँदा इन्डपोइन्ट रुटहरू पठाइन्छन्, त्यसैले बदलिएको रुट सेट जोडिएर रहने क्लाइन्टसम्म कहिल्यै पुग्दैन। समर्थित क्लाइन्टमार्फत विच्छेद गरी पुनः जोड्नुहोस्, त्यसपछि नयाँ रुटहरू मेसिनमा छन् भनी पुष्टि गर्नुहोस्।

अन्तमा, जडान लगलाई क्लाइन्टले पाएको ठेगानासँग सम्बन्धित गर्नुहोस्, र एकभन्दा बढी एसोसिएसनमा पुग्न पर्याप्त पटक परीक्षण दोहोर्याउनुहोस्। सुधारपछिको एउटा सफल अनुरोधले एउटा मार्ग चल्छ भनी प्रमाणित गर्छ, र टिकट अर्कोबारे थियो।