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 असलेल्या सबनेटऐवजी मार्ग, प्रभावी स्रोत आणि इच्छित सेवा पोर्ट यांची पुष्टी करा.

कामाचा क्रम: चार-भाग आवश्यकता लिहा, गट संलग्नतांना जोडा, संसाधन नियम पोर्टपर्यंत मर्यादित करा, एक परवानगी आणि एक नकार तपासा, आणि त्यानंतरच राउटिंग कारणांसाठी सबनेट विभागण्याचा विचार करा.