AWS Client VPN का नियम स्रोतमा हुनुपर्छ, सबनेटमा होइन

कर्मचारीहरूले VPC मा रहेको एउटा अनुप्रयोगमा पुग्नुपर्छ र एउटै इन्स्ट्यान्सको डाटाबेस श्रोतामा पुग्नु हुँदैन, त्यसैले कसैले VPN endpoint का लागि दोस्रो सार्वजनिक सबनेट थप्छ र आवश्यकता पूरा भयो भनी घोषणा गर्छ। सबनेटको स्थानले राउटिङ र उपलब्धता बदल्छ। यसले एउटै पोर्ट पनि दिँदैन वा रोक्दैन। आवश्यकता व्यक्त गर्ने अनुमति गन्तव्यमा, स्रोतको सुरक्षा समूहमा रहन्छ, र VPN सिमाले त्यो नियमले सन्दर्भ गर्ने ह्यान्डल प्रदान गर्छ।

सबनेटको स्थान राउटिङ हो, अधिकार होइन

endpoint को नेटवर्क सम्बद्धता कहाँ छ भन्नेले कुन रुट तालिकाले ग्राहक ट्राफिक बोक्छ र कुन उपलब्धता क्षेत्रहरू खराबीबाट बाँच्छन् भन्ने निर्धारण गर्छ। त्यो ट्राफिक कुन इन्स्ट्यान्सको कुन पोर्टसम्म पुग्न सक्छ भन्ने यसले केही भन्दैन। एउटै सबनेटसँग सम्बद्ध दुई ग्राहकहरू अझै पनि एउटै स्रोत पहिचानसहित आउँछन्, र स्रोतले तिनीहरूलाई सबनेटको नामले छुट्याउन सक्दैन।

बरु आवश्यकताबाट सुरु गर्नुहोस्: कसले कल गर्छ, कुन स्रोत, कुन सेवा पोर्ट र कुन दिशा। त्यसपछि ती चार कुरा गन्तव्यमा व्यक्त गर्न सक्ने नियम मोडेल छान्नुहोस्। त्यो ढाँचाले सामान्यतया थप सबनेटलाई डिजाइनबाट पूर्ण रूपमा हटाउँछ।

Client VPN सम्बद्धता समूह नै त्यो ह्यान्डल हो

सबनेटसँग सम्बद्ध AWS Client VPN endpoint का लागि अभिलेखित व्यवस्था विशिष्ट छ। इच्छित सुरक्षा समूह endpoint का लक्ष्य नेटवर्क सम्बद्धताहरूमा लागू गर्नुहोस्, त्यसपछि त्यो Client VPN समूहलाई स्रोतका रूपमा प्रयोग गरी स्रोतको सुरक्षा समूहमा आवश्यक ट्राफिकलाई अनुमति दिनुहोस्।

विशेष रूपमा, अनुप्रयोग इन्स्ट्यान्सको समूहले सम्बद्धता समूहबाट अनुप्रयोग पोर्टलाई मात्र अनुमति दिन्छ, अरू केही होइन। AWS को स्रोत पहुँच प्रक्रिया ले त्यो सम्बन्ध वर्णन गर्छ, र endpoint जुनसुकै सबनेटसँग सम्बद्ध हुन्छ त्यहाँ एउटै समूह नीति राख्नु उपयुक्त हुन्छ, किनभने फरक समूहसँगको पुरानो सम्बद्धताले सिमालाई चुपचाप फराकिलो बनाउँछ।

त्यो नियमले कसैलाई प्रमाणित गर्दैन। लगइन छुट्टै नियन्त्रण हो, र स्रोतसम्मको मार्ग तेस्रो हो। अनुरोध आउनु अघि तीनवटै सत्य हुनुपर्छ। कुन असफल हुन्छ त्यसले कुन सुधार सही हो भन्ने निर्धारण गर्छ, र नियम परिवर्तन पहिलोका लागि मात्र सही उत्तर हो।

एउटा सम्बद्धता समूहले छुट्याउन नसक्ने कुरा

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

सूक्ष्म भिन्नताहरू अनुप्रयोगका हुन्। अधिकांश कर्मचारीका लागि बन्द रहनुपर्ने डाटाबेस श्रोतालाई समूह सदस्यता व्यवस्थित रहने आशा गर्नुभन्दा अनुमति दिइएको प्रिफिक्समा बिल्कुलै पहुँचयोग्य नहुने गरी राख्नु राम्रो सुरक्षा हो।

समूहको नाम बदल्नाले पहिचान सिर्जना गर्दैन, र प्रत्येक टोलीका लागि यसको प्रतिलिपि बनाउनाले जाँच्नुपर्ने सम्बद्धताहरू मात्र बढाउँछ।

त्यो नियम हरेक VPN डिजाइनमा प्रतिलिपि नगर्नुहोस्

स्वयं-व्यवस्थित EC2 VPN गेटवे, रुट गरिएको निरीक्षण उपकरण र व्यवस्थित Client VPN तीन फरक प्याकेट मार्ग हुन्। कुन स्रोत ठेगाना वास्तवमा स्रोतसम्म पुग्छ, बीचमा अनुवाद हुन्छ कि हुँदैन, र त्यो मार्गमा सेवाले कुन सन्दर्भ संयन्त्रहरूलाई समर्थन गर्छ भन्ने निर्धारण गर्नुहोस्।

मध्यस्थ उपकरणबाट ट्राफिक अगाडि बढाउँदा स्रोत सुरक्षा समूह सन्दर्भ इन्स्ट्यान्स-देखि-इन्स्ट्यान्स सिधा ट्राफिकले जस्तो सुरक्षित राख्दैन। यस्ता डिजाइनहरूलाई समूह सन्दर्भको सट्टा उपयुक्त निजी स्रोत ठेगाना वा CIDR आवश्यक पर्न सक्छ भनी AWS अभिलेख गर्छ। व्यवस्थित Client VPN को प्रक्रिया प्रत्येक गेटवेको संलग्न समूहले पठाइएका प्याकेटका लागि सार्वभौमिक पहिचान टोकनका रूपमा काम गर्छ भन्ने प्रमाण होइन।

मार्गमा एउटा NAT हप्ले अनुमान तोड्न पर्याप्त हुन्छ, र खराबी अवस्थित तर कहिल्यै नमिल्ने नियमजस्तो देखिन्छ।

प्रभावकारी सिमाको समीक्षा गर्नुहोस्

स्रोतसँग जोडिएको प्रत्येक सुरक्षा समूह पढ्नुहोस्, किनभने अनुमति नियमहरू जोडिन्छन् र साँघुरो नियमले अर्को समूहको फराकिलो नियम रद्द गर्दैन। त्यसपछि नेटवर्क ACL, होस्ट फायरवाल र अनुप्रयोगको आफ्नै अधिकार जाँच्नुहोस्, जो फरक गल्ती भएका फरक तह हुन्।

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

कार्यक्रम: चार-भागको आवश्यकता लेख्नुहोस्, समूहलाई सम्बद्धताहरूसँग जोड्नुहोस्, स्रोत नियमलाई पोर्टसम्म सीमित गर्नुहोस्, एउटा अनुमति र एउटा अस्वीकृति प्रमाणित गर्नुहोस्, र त्यसपछि मात्र राउटिङ कारणले सबनेट विभाजन गर्ने विचार गर्नुहोस्।