VPN के लिए क्लाउड सुरक्षा समूह: श्रोता खोलें, सब कुछ नहीं

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

नियम से पहले प्रोटोकॉल का नाम बताएँ

नियम यानी प्रोटोकॉल, पोर्ट श्रेणी और स्रोत। WireGuard UDP पर सुनता है, सामान्यतः 51820. OpenVPN आमतौर पर UDP या TCP 1194 होता है, यह इस पर निर्भर है कि इसे कैसे कॉन्फ़िगर किया गया। IPsec को UDP 500 और 4500 पर IKE विनिमय चाहिए, साथ ही स्वयं ESP प्रोटोकॉल, जो पोर्ट नहीं बल्कि प्रोटोकॉल संख्या है। बाकी नियम TCP हैं इसलिए TCP मान लेना ऐसा नियम बनाता है जो सही दिखता है और किसी से मेल नहीं खाता।

श्रोता को चल रही सेवा से पढ़ें, किसी ट्यूटोरियल से नहीं. एक पते से बंधा डेमॉन दूसरे पते पर आने वाला ट्रैफ़िक स्वीकार नहीं करेगा।

स्रोत को पूरे इंटरनेट के बजाय उस क्लाइंट श्रेणी तक सीमित करें जिसकी डिज़ाइन अनुमति देती है।

सुरक्षा समूह स्टेटफ़ुल हैं; सबनेट ACL नहीं

सुरक्षा समूह स्टेटफ़ुल हैं और केवल अनुमति देते हैं: अनुमत इनबाउंड प्रवाह को उसके उत्तर स्वतः मिल जाते हैं, और सोचने के लिए कोई अस्वीकृति नियम नहीं है। सबनेट ACL स्टेटलेस हैं और दोनों दिशाओं में मूल्यांकित होते हैं, इसलिए संबंधित आउटबाउंड अल्पकालिक श्रेणी के बिना इनबाउंड अनुमति फिर भी विफल होती है। यही अंतर कंसोल में सही दिखने वाले कई नियमों की व्याख्या करता है।

यह भी पुष्टि करें कि चल रहे एंडपॉइंट से कौन-सी नीति जुड़ी है, क्योंकि एक इंस्टेंस में एक से अधिक समूह हो सकते हैं और बिना जुड़े समूह का नियम कुछ नहीं बदलता।

प्रभावी नीति जुड़े हुए का संघ है, वह फ़ाइल नहीं जिसे आपने संपादित किया।

होस्ट फ़ायरवॉल एक अलग सीमा है

क्लाउड नीति ट्रैफ़िक को नेटवर्क इंटरफ़ेस तक अनुमति देती है, और फिर ऑपरेटिंग सिस्टम तय करता है कि डेमॉन उसे देखेगा या नहीं। डिफ़ॉल्ट अस्वीकृति नीति वाला होस्ट फ़ायरवॉल उस पैकेट को गिरा देगा जिसे सुरक्षा समूह ने अनुमति दी थी, और क्लाउड कंसोल कोई अस्वीकृति नहीं दिखाएगा क्योंकि उसकी कभी कोई राय नहीं थी। दोनों जाँचें, उसी क्रम में जिसमें पैकेट उनसे मिलता है।

यदि होस्ट वितरण के फ़ायरवॉल फ़्रंटएंड का उपयोग करता है, तो प्रोफ़ाइल नाम के बजाय अंतर्निहित नियमों की पुष्टि करें, क्योंकि प्रोफ़ाइल सक्रिय हो सकता है जबकि पोर्ट बंद हो।

इंटरफ़ेस पर कैप्चर बताता है कि किस सीमा ने पैकेट गिराया।

श्रोता को अनुमति देना क्लाइंटों को रूट करना नहीं है

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

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

रूटिंग को अपने सत्यापन के साथ अलग परिवर्तन के रूप में ठीक करें, और ध्यान दें कि फ़ॉरवर्ड करने वाले गेटवे को गंतव्य की अनुमति देने वाली एग्रेस नीति भी चाहिए।

वापसी का रास्ता रखें, फिर नियम संकीर्ण करें

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

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

जुड़ाव का भी दस्तावेज़ीकरण करें, अन्यथा प्रतिस्थापन इंटरफ़ेस चुपचाप नीति खो देगा।