VPN का लागि क्लाउड सुरक्षा समूह: श्रोता खोल्नुहोस्, सबै होइन

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

नियमभन्दा पहिले प्रोटोकलको नाम भन्नुहोस्

नियम भनेको प्रोटोकल, पोर्ट दायरा र स्रोत हो। WireGuard UDP मा सुन्छ, सामान्यतया 51820. OpenVPN कन्फिगरेसन अनुसार सामान्यतया UDP वा TCP 1194 हो। IPsec लाई UDP 500 र 4500 मा IKE आदानप्रदान र ESP प्रोटोकल आफै चाहिन्छ, जो पोर्ट होइन प्रोटोकल नम्बर हो। अरू नियम TCP छन् भनेर TCP अनुमान गर्नु ठीक देखिने तर केहीसँग नमिल्ने नियम बनाउने बाटो हो।

श्रोता चलिरहेको सेवाबाट पढ्नुहोस्, ट्युटोरियलबाट होइन. एउटा ठेगानामा बाँधिएको डेमन अर्को ठेगानामा आउने ट्राफिक स्वीकार गर्दैन।

स्रोतलाई सम्पूर्ण इन्टरनेटको सट्टा डिजाइनले अनुमति दिने क्लाइन्ट दायरामा सीमित गर्नुहोस्।

सुरक्षा समूह स्टेटफुल छन्; सबनेट ACL होइनन्

सुरक्षा समूह स्टेटफुल छन् र अनुमति मात्र दिन्छन्: अनुमति पाएको इनबाउन्ड प्रवाहले आफ्ना जवाफ स्वतः पाउँछ, र सोच्नुपर्ने कुनै अस्वीकृति नियम छैन। सबनेट ACL स्टेटलेस छन् र दुवै दिशामा मूल्याङ्कन हुन्छन्, त्यसैले सम्बन्धित आउटबाउन्ड अस्थायी दायरा बिना इनबाउन्ड अनुमति अझै असफल हुन्छ। यही भिन्नताले कन्सोलमा ठीक देखिने धेरै नियम व्याख्या गर्छ।

चलिरहेको एन्डपोइन्टमा कुन नीति जोडिएको छ त्यो पनि पुष्टि गर्नुहोस्, किनकि एउटा इन्स्ट्यान्समा एकभन्दा बढी समूह हुन सक्छ र नजोडिएको समूहको नियमले केही बदल्दैन।

प्रभावकारी नीति जोडिएकाहरूको संघ हो, तपाईंले सम्पादन गरेको फाइल होइन।

होस्ट फायरवाल अलग सीमा हो

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

यदि होस्टले वितरणको फायरवाल फ्रन्टएन्ड प्रयोग गर्छ भने प्रोफाइलको नाम होइन, आधारभूत नियमहरू पुष्टि गर्नुहोस्, किनकि प्रोफाइल सक्रिय हुँदा पनि पोर्ट बन्द हुन सक्छ।

इन्टरफेसमा गरिएको क्याप्चरले कुन सीमाले प्याकेट खसाल्यो भन्ने बताउँछ।

श्रोतालाई अनुमति दिनु क्लाइन्टहरूलाई रुट गर्नु होइन

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

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

रुटिङलाई आफ्नै प्रमाणीकरणसहित अलग परिवर्तनको रूपमा सुधार्नुहोस्, र फर्वार्ड गर्ने गेटवेलाई गन्तव्यलाई अनुमति दिने एग्रेस नीति पनि चाहिन्छ भनी नोट गर्नुहोस्।

फर्कने बाटो राख्नुहोस्, त्यसपछि नियम साँघुरो गर्नुहोस्

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

साँघुरो अनुमति काम गर्ने बित्तिकै कुनै पनि प्रयोगात्मक फराकिलो अनुमति हटाउनुहोस्, र नियम किन छ भनी लेख्नुहोस्। AWS सुरक्षा समूहहरूको स्टेटफुल व्यवहार को दस्तावेजीकरण गर्छ, र कसैले सर्टकटको रूपमा फराकिलो दायरा सुझाव दिँदा त्यही दस्तावेज उद्धृत गर्नुपर्छ।

जोडाइको पनि दस्तावेजीकरण गर्नुहोस्, नत्र प्रतिस्थापन इन्टरफेसले चुपचाप नीति गुमाउनेछ।