VPN सर्भरका लागि क्लाउड फायरवाल र होस्ट फायरवाल

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

छेउबाट सुरु गरेर भित्र जानुहोस्

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

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

पाहुनालाई छुनुअघि क्लाउड नीति पढ्नुहोस्

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

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

पहिले श्रोता, त्यसपछि इनपुट शृङ्खला पुष्टि गर्नुहोस्

इन्स्ट्यान्समा, VPN प्रक्रिया तपाईंले अपेक्षा गरेको ठेगाना र पोर्टमा बाँधिएको छ कि छैन जाँच्नुहोस्, उदाहरणका लागि ss -lntp 'sport = :1194' प्रयोग गरेर। 127.0.0.1 मा मात्र बाँधिएको डेमनले स्थानीय क्लाइन्ट स्वीकार्छ र सुरुङबाट केही पनि स्वीकार्दैन, जुन बाहिरबाट ठ्याक्कै फिल्टर गरिएको पोर्टजस्तै देखिन्छ।

त्यसपछि स्थानीय नियमहरू तिनलाई बदल्न प्रयोग गर्ने त्यही वाक्यरचनामा पढ्नुहोस्, जस्तै iptables -S INPUT वा nft list chain inet filter input. फाइलमा लेखिएको तर कहिल्यै लोड नगरिएको नियम, वा मिल्ने अनुमति नभएको पूर्वनिर्धारित ड्रप, प्याकेटहरू चुपचाप फाल्छ। अगाडि पठाउने गेटवेका लागि पठाउने र उल्टो मार्गका सेटिङ पनि जाँच्नुहोस्। इन्स्ट्यान्सलाई लक्षित नगरी यसबाट रुट हुने प्याकेटलाई के हुन्छ भन्ने तिनैले निर्धारण गर्छन्।

एउटा तहमा स्टेटफुल, अर्कोमा स्टेटलेस

सुरक्षा समूहहरूले आफूले अनुमति दिएका प्रवाह सम्झन्छन् र प्रतिक्रियाहरू फर्किन दिन्छन्। सबनेट पहुँच नियन्त्रण सूची र धेरै होस्ट फायरवालले यस्तो अवस्था राख्दैनन्, त्यसैले बाहिर जाने दिशा मात्र समेट्ने नियमले अनुरोध पार गराउँछ र प्रतिक्रिया फाल्छ। दोस्रो तहको नियम नपढी तहहरूबीच फर्किने ट्राफिकको अनुमान कहिल्यै नबोक्नुहोस् (second layer's rule)।

खाताको हरेक नियम पढ्नुभन्दा काउन्टरहरूले छिटो टुङ्गो लगाउँछन्। बढ्दै गएको काउन्टर भनेको प्याकेट त्यहाँ पुग्यो र त्यहीँ फालियो, जबकि शून्यमा जमेको काउन्टर भनेको त्यो त्यहाँसम्म पुगेन; नियमहरू काउन्टरसहित लोड गरिएको खण्डमा iptables -vnL INPUT र nft list ruleset ती संख्याहरू देखाउँछन्।

जीवित सत्रले होइन, नयाँ सत्रले परीक्षण गर्नुहोस्

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

टाढाको नीति सम्पादन गर्नुअघि तपाईंले बदल्न लागेको मार्गमा निर्भर नहुने फर्किने बाटो सुनिश्चित गर्नुहोस्। त्यसपछि VPN परीक्षणको छेउमा दोस्रो प्रशासनिक सत्र खोल्नुहोस्: पहिले स्थापित भएको सत्रले नयाँलाई रोक्ने नियमभन्दा लामो समय टिक्न सक्छ। दुवै नीतिका मालिक नोट गर्नुहोस् ताकि कुनै पुनर्निर्माणले आधा मार्ग फर्काउन नसकोस्; यदि दुवै तह सहमत छन् र सुरुङ अझै असफल हुन्छ भने, पाहुनाको इन्टरफेसमा क्याप्चर गरेर क्लाइन्टले साँच्चै प्रयोग गर्ने ठेगाना र पोर्ट जाँच्नुहोस्।