सबै कुरा एउटै होस्टमा फर्वार्ड गर्ने, वा पोर्ट पनि पुनःलेखन गर्ने?

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

पहिलो सर्त: नियमले कुन क्षेत्रहरू बदल्छ?

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

मेनु लेबल होइन, वास्तविक नियम पढ्नुहोस्। DMZ वा सबै पोर्ट भन्ने स्क्रिनले मनसाय वर्णन गर्छ, प्याकेटको मार्ग होइन। Netfilter NAT कागजातले दुई अनुवाद अलग गर्छ, र तपाईंको अगाडिको राउटर उपभोक्ता उपकरण भए पनि यो सही मानसिक मोडेल हो।

दुई क्षेत्र, दुई फरक प्रश्न।

दोस्रो सर्त: राखिएका पोर्टहरूमा के सुनिरहेको छ?

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

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

रोज्नुअघि श्रोताको सूची बनाउनुहोस्।

तेस्रो सर्त: बाहिरी प्रवेश कति फराकिलो छ?

एउटा छानिएको पोर्ट प्रकाशित गर्नु दायरा प्रकाशित गर्नुभन्दा साँघुरो हुन्छ, र दुवै सबै कुरा स्वीकार्नुभन्दा साँघुरा हुन्छन्। बाहिरी चौडाइ र भित्री अनुवाद स्वतन्त्र छनोट हुन्, र अधिकांश भ्रम एउटा बदल्दा अर्को वर्णन गर्दा आउँछ।

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

अनुवादित अन्त्य बिन्दु पूरै लेख्नुहोस्: प्रोटोकल, बाहिरी पोर्ट, भित्री ठेगाना, भित्री पोर्ट।

कुनै पनि नियमले तपाईंलाई नदिने कुरा

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

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

जोखिम विश्लेषण के के सम्म पुग्न सक्छ भन्ने हो, स्क्रिनको लेबल होइन।

अनुवादित अन्त्य बिन्दु हातमा लिएर निर्णय गर्नुहोस्

नियमको नतिजा वाक्यका रूपमा लेख्नुहोस्: सार्वजनिक UDP पोर्ट X ठेगाना Y पोर्ट Z मा पुग्छ। त्यसपछि Y मा कुन सेवाले Z मा जवाफ दिन सक्छन् र तिनीहरू कसको स्वामित्वमा छन् भनी सोध्नुहोस्।

nft list ruleset

यदि जवाफ तपाईंले चाहेको त्यही एउटा श्रोता हो भने, नियमले आफ्नो काम गरिरहेको छ।

यदि जवाफ धेरै छ भने, इन्टरफेसले त्यसलाई त्यसो भने पनि नभने पनि, तपाईंले पूरै होस्टमा फर्वार्डिङ रोज्नुभएको छ।