सब कुछ एक ही होस्ट पर फ़ॉरवर्ड करें या पोर्ट भी बदलें?

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

पहली शर्त: नियम कौन से फ़ील्ड बदलता है?

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

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

दो फ़ील्ड, दो अलग प्रश्न।

दूसरी शर्त: संरक्षित पोर्ट पर कौन सुन रहा है?

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

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

चुनने से पहले श्रोता की सूची बनाएँ।

तीसरी शर्त: बाहरी प्रवेश कितना चौड़ा है?

एक चुना हुआ पोर्ट प्रकाशित करना एक श्रेणी प्रकाशित करने से संकरा है, और दोनों सब कुछ स्वीकार करने से संकरे हैं। बाहरी चौड़ाई और आंतरिक अनुवाद स्वतंत्र चयन हैं, और अधिकांश भ्रम एक को बदलते हुए दूसरे का वर्णन करने से आता है।

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

अनुवादित एंडपॉइंट पूरा लिखें: प्रोटोकॉल, बाहरी पोर्ट, आंतरिक पता, आंतरिक पोर्ट।

जो दोनों में से कोई नियम आपको नहीं देता

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

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

जोखिम विश्लेषण इस बारे में है कि क्या कहाँ तक पहुँच सकता है, स्क्रीन पर के लेबल के बारे में नहीं।

अनुवादित एंडपॉइंट हाथ में लेकर निर्णय लें

नियम के परिणाम को वाक्य के रूप में लिखें: सार्वजनिक UDP पोर्ट X पता Y पोर्ट Z तक पहुँचता है। फिर पूछें कि Y पर कौन सी सेवाएँ Z पर उत्तर दे सकती हैं और उनका मालिक कौन है।

nft list ruleset

यदि उत्तर वही एक श्रोता है जिसका आपने इरादा किया था, तो नियम अपना काम कर रहा है।

यदि उत्तर कई हैं, तो आपने पूरे होस्ट पर फ़ॉरवर्डिंग चुनी है, चाहे इंटरफ़ेस ने उसे ऐसा कहा हो या नहीं।