EC2 का लागि VPN मात्र नियम: जोडिएको हरेक सुरक्षा समूह सहमत हुनुपर्छ

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

नियम लेख्नु अघि सेवा लेख्नुहोस्

सही गन्तव्य, प्रोटोकल र पोर्टबाट सुरु गर्नुहोस्, र सेवा वास्तवमा सुन्ने नेटवर्क इन्टरफेसबाट पनि। धेरै इन्टरफेस वा एउटै पोर्टमा धेरै सेवा भएको इन्स्ट्यान्सका लागि हरेक इन्टरफेसको अडिट आवश्यक हुन्छ, किनभने जोडिएका समूह फरक हुन सक्छन्। त्यसपछि निर्धारण गर्नुहोस् त्यो इन्टरफेसले VPN प्रयोगकर्ताका लागि वास्तवमा कुन स्रोत ठेगाना प्राप्त गर्छ, क्लाइन्टले आफ्नै जडान विन्डोमा देखाउने ठेगाना होइन।

अनुवाद र राउटिङ संलग्न भएपछि यी दुई ठेगाना मानिसहरूले अपेक्षा गरेभन्दा धेरै पटक फरक पर्छन्।

तीन स्रोत मोडेल, तीन फरक नियम

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

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

हरेक जोडिएको समूहमा संघ पढ्नुहोस्

इन्स्ट्यान्स खोल्नुहोस्, यसको नेटवर्क इन्टरफेस खोज्नुहोस्, र यसमा जोडिएको हरेक सुरक्षा समूह सूचीबद्ध गर्नुहोस्। हरेकका लागि, तपाईंको प्रोटोकल र पोर्ट समेट्ने हरेक नियम जाँच्नुहोस्, फराकिला पोर्ट दायरा र दुवै ठेगाना परिवार सहित। 0.0.0.0/0 बाट IPv4 नियमले तपाईंलाई ::/0 जाँच्नबाट छुट दिँदैन, र सबै ट्राफिक अनुमति दिने नियमले पोर्टको प्रश्न पूरै लुकाउँछ। यो सूचीपछि मात्र सेवाका लागि प्रभावकारी अनुमति के हो भन्न सक्नुहुन्छ।

AWS नियम सन्दर्भले सुरक्षा समूहहरूलाई मात्र-अनुमति दिने भनी वर्णन गर्छ र सबै जोडिएका समूहका नियमहरू एकत्र गरिन्छ भन्छ, र यही यो असफलतापछिको पूरा संयन्त्र हो।

नेटवर्क ACL एउटा छुट्टै, स्थितिहीन नीति हो जसमा क्रमबद्ध अनुमति र अस्वीकृति प्रविष्टिहरू हुन्छन्, र तिनीहरूको मूल्याङ्कन इन्स्ट्यान्समा होइन सबनेटमा हुन्छ।

अस्वीकृतिको पर्खालले जवाफ नदिनुहोस्

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

इन्स्ट्यान्सबाट सार्वजनिक ठेगाना हटाउनु बलियो ग्यारेन्टी हो, र यो प्रशासनिक र अनुप्रयोग परिणाम भएको वास्तुशिल्प परिवर्तन पनि हो, अनुमति सूचीमा चेकबक्स होइन।

नयाँ सत्रसँग परीक्षण गर्नुहोस् र भित्र पस्ने बाटो राख्नुहोस्

कुनै पनि विद्यमान अनुमति हटाउनु अघि स्वीकृत स्वतन्त्र प्रशासनिक बाटो पुष्टि गर्नुहोस्, किनभने तपाईंले मेट्न लागेको नियम त्यही हुन सक्छ जसमा तपाईंको सत्र पुनःप्राप्ति निर्भर छ। त्यसपछि VPN बाट नयाँ अनुमति दिइएको जडान र स्वीकृत गैर-VPN परीक्षण बाटोबाट नयाँ अस्वीकृत जडान परीक्षण गर्नुहोस्। विद्यमान ट्र्याक गरिएका सत्रहरू नियम परिवर्तन सहन्छन् जसले पुराना खुला शेलहरूलाई स्वीकृतिको प्रमाणका रूपमा बेकाम्मा बनाउँछ।

अन्तमा, अनुप्रयोगको आफ्नै अधिकृतता यथास्थान राख्नुहोस्। अनुवादित कर्पोरेट एग्रेसले सयौं मानिसको प्रतिनिधित्व गर्न सक्छ, र नेटवर्क प्रवेशले कहिल्यै व्यक्तिगत प्रयोगकर्ता वा उसको यन्त्र पहिचान गरेन।