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 तीन भिन्न पैकेट पथ हैं। तय करें कि कौन-सा स्रोत पता वास्तव में संसाधन तक पहुँचता है, बीच में अनुवाद होता है या नहीं, और उस पथ पर सेवा किन संदर्भ तंत्रों का समर्थन करती है।

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

पथ पर एक NAT हॉप ही धारणा तोड़ने के लिए काफ़ी है, और विफलता ऐसे नियम जैसी दिखती है जो मौजूद है पर कभी मेल नहीं खाता।

प्रभावी सीमा की समीक्षा करें

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

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

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