VPN साठी क्लाउड सुरक्षा गट: श्रोता उघडा, सर्व काही नाही

VPN सर्व्हर चालू आहे, क्लायंटची वेळ संपत आहे, आणि पहिली प्रतिक्रिया म्हणजे सुरक्षा गटात सर्व काही परवानगी देणारा नियम जोडणे. कधीकधी त्यामुळे काम होते, आणि तोच सर्वात वाईट परिणाम आहे, कारण आता कोणती सीमा प्रत्यक्षात बंद झाली हे कोणालाच माहीत नाही. क्लायंट आणि डीमनमध्ये चार वेगळे फिल्टर आहेत, आणि त्यापैकी फक्त एक सुरक्षा गट आहे.

नियमापूर्वी प्रोटोकॉलचे नाव सांगा

नियम म्हणजे प्रोटोकॉल, पोर्ट श्रेणी आणि स्रोत. WireGuard UDP वर ऐकतो, सामान्यतः 51820. OpenVPN कॉन्फिगरेशननुसार सामान्यतः UDP किंवा TCP 1194 असतो. IPsec ला UDP 500 आणि 4500 वर IKE देवाणघेवाण तसेच ESP प्रोटोकॉल स्वतः लागतो, जो पोर्ट नसून प्रोटोकॉल क्रमांक आहे. इतर नियम TCP आहेत म्हणून TCP गृहीत धरणे हे बरोबर दिसणारे आणि कोणाशीही जुळणारे नसलेले नियम तयार करते.

श्रोता चालू सेवेतून वाचा, ट्युटोरियलमधून नाही. एका पत्त्याला बांधलेला डीमन दुसऱ्या पत्त्यावर येणारी रहदारी स्वीकारणार नाही.

स्रोत संपूर्ण इंटरनेटऐवजी डिझाइन परवानगी देते त्या क्लायंट श्रेणीपर्यंत मर्यादित करा.

सुरक्षा गट स्टेटफुल आहेत; सबनेट ACL नाहीत

सुरक्षा गट स्टेटफुल आहेत आणि फक्त परवानगी देतात: परवानगी दिलेला इनबाउंड प्रवाह त्याची उत्तरे स्वयंचलितपणे मिळवतो, आणि विचार करण्यासारखा नकार नियम नाही. सबनेट ACL स्टेटलेस आहेत आणि दोन्ही दिशांना मूल्यांकन केले जाते, म्हणून संबंधित आउटबाउंड तात्पुरत्या श्रेणीशिवाय इनबाउंड परवानगी तरीही अयशस्वी होते. हाच फरक कन्सोलमध्ये बरोबर दिसणाऱ्या अनेक नियमांचे स्पष्टीकरण देतो.

चालू एंडपॉइंटला कोणते धोरण जोडले आहे याचीही खात्री करा, कारण एका इन्स्टन्समध्ये एकापेक्षा जास्त गट असू शकतात आणि न जोडलेल्या गटातील नियम काहीही बदलत नाही.

प्रभावी धोरण म्हणजे जोडलेल्यांचा संघ, तुम्ही संपादित केलेली फाइल नाही.

होस्ट फायरवॉल वेगळी सीमा आहे

क्लाउड धोरण रहदारीला नेटवर्क इंटरफेसपर्यंत परवानगी देते, आणि नंतर ऑपरेटिंग सिस्टम ठरवते की डीमन ती पाहील का. डीफॉल्ट नकार धोरण असलेला होस्ट फायरवॉल सुरक्षा गटाने परवानगी दिलेला पॅकेट टाकून देईल, आणि क्लाउड कन्सोल कोणताही नकार दाखवणार नाही कारण त्याला कधीच मत नव्हते. पॅकेट ज्या क्रमाने त्यांना भेटतो त्या क्रमाने दोन्ही तपासा.

होस्ट वितरणाचा फायरवॉल फ्रंटएंड वापरत असल्यास, प्रोफाइल नावाऐवजी मूलभूत नियमांची खात्री करा, कारण प्रोफाइल सक्रिय असतानाही पोर्ट बंद असू शकतो.

इंटरफेसवरील कॅप्चर सांगते कोणत्या सीमेने पॅकेट टाकून दिले.

श्रोत्याला परवानगी देणे म्हणजे क्लायंटना राउट करणे नाही

क्लायंट रहदारी फॉरवर्ड करणाऱ्या VPN गेटवेला उघड्या पोर्टपेक्षा जास्त लागते. IP फॉरवर्डिंग, टनेल इंटरफेसपासून गंतव्य नेटवर्कपर्यंत प्रवाहाला परवानगी देणारे धोरण, आणि प्लॅटफॉर्मला स्वतःला उद्देशून नसलेली रहदारी टाकून न देण्यासाठी इंटरफेसवर बंद केलेली स्रोत-गंतव्य तपासणी लागते. यापैकी काहीही श्रोता नियम तयार करत नाही.

इथेच कार्यरत हँडशेक आणि तुटलेला डेटा मार्ग वेगळे होतात, आणि म्हणूनच टनेलची स्थिती निरोगी दिसू शकते तरी काहीही लोड होत नाही.

राउटिंगला स्वतःच्या पडताळणीसह वेगळा बदल म्हणून दुरुस्त करा, आणि फॉरवर्ड करणाऱ्या गेटवेला गंतव्याला परवानगी देणारे एग्रेस धोरणही लागते हे नोंदवा.

परत जाण्याचा मार्ग ठेवा, मग नियम अरुंद करा

दूरस्थ फायरवॉल धोरण बदलण्यापूर्वी स्वतंत्र व्यवस्थापन मार्ग आहे याची खात्री करा, जसे सत्र व्यवस्थापक, सिरियल कन्सोल किंवा बँडबाहेरील नेटवर्क. तुम्ही संपादित करत असलेल्या नियमातूनच एकमेव व्यवस्थापन मार्ग जात असल्यास तुमच्याकडे पुनर्प्राप्ती नाही. नंतर अरुंद नियम लागू करा, खऱ्या क्लायंटवरून चाचणी करा, आणि प्रयत्नाला सर्व्हर-बाजूच्या पुराव्याशी जोडा. त्याच मशीनवरील दुसऱ्या सेवेचे उत्तर श्रोत्यापर्यंत पोहोचल्याचा पुरावा नाही.

अरुंद परवानगी काम करताच कोणतीही प्रायोगिक विस्तृत परवानगी काढून टाका, आणि नियम का आहे ते नोंदवा. AWS सुरक्षा गटांच्या स्टेटफुल वर्तनाचे दस्तऐवजीकरण करते, आणि जेव्हा कोणी शॉर्टकट म्हणून विस्तृत श्रेणी सुचवेल तेव्हा तोच दस्तऐवज उद्धृत करावा.

जोडणीचेही दस्तऐवजीकरण करा, अन्यथा बदली इंटरफेस धोरण गुपचूप गमावेल.