सर्व काही एकाच होस्टवर फॉर्वर्ड करायचे की पोर्टही पुन्हा लिहायचा?

तुमच्या VPN सर्व्हरवर सर्व काही फॉर्वर्ड करणे हे दोन अगदी वेगळ्या नियमांचे वर्णन करू शकते. एक गंतव्य पत्ता बदलतो आणि येणारा पोर्ट ठेवतो; दुसरा पोर्टही एकाच श्रोत्यावर पुन्हा लिहितो. एक्सपोजर सारखा नाही, आणि निर्णय राउटरचा इंटरफेस वापरतो त्या लेबलवर नाही, तर तीन अटींवर अवलंबून आहे.

पहिली अट: नियम कोणती क्षेत्रे बदलतो?

गंतव्य पत्ता भाषांतर आणि गंतव्य पोर्ट भाषांतर या वेगळ्या क्रिया आहेत. नियम फक्त पहिली किंवा दोन्ही एकत्र करू शकतो, आणि फरक लक्ष्य होस्टवरील कोणत्या सेवा पोहोचण्यायोग्य आहेत हे ठरवतो. बहुतेक विक्रेता इंटरफेस ती निवड एका लेबलमागे लपवतात. अंतर्निहित नियम वाचणे हाच तुम्हाला कोणता मिळाला हे जाणून घेण्याचा एकमेव मार्ग आहे.

मेनू लेबल नाही, प्रत्यक्ष नियम वाचा. DMZ किंवा सर्व पोर्ट असे सांगणारी स्क्रीन हेतूचे वर्णन करते, पॅकेटच्या मार्गाचे नाही. Netfilter NAT दस्तऐवज दोन्ही भाषांतरे वेगळी करतो, आणि तुमच्यासमोरील राउटर ग्राहक उपकरण असले तरी हे योग्य मानसिक मॉडेल आहे.

दोन क्षेत्रे, दोन वेगळे प्रश्न.

दुसरी अट: राखीव पोर्टवर काय ऐकत आहे?

नियम येणारा पोर्ट ठेवत असल्यास, येणारा प्रत्येक पोर्ट VPN होस्टवरील त्याच क्रमांकावर पोहोचवला जातो, त्या होस्टच्या इनपुट धोरणाच्या अधीन. यात अशा सेवांचाही समावेश आहे ज्या ऐकत आहेत हे तुम्ही विसरला असाल. नियमाने त्या सेवा तयार केल्या नाहीत, आणि आता तोच त्यांच्यापर्यंतचा मार्ग आहे.

नियम पोर्ट पुन्हा लिहित असल्यास उलटे घडते: अनेक बाह्य पोर्ट एकाच श्रोत्यावर एकत्र येतात, आणि होस्टवर दुसरे काहीही त्या नियमातून पोहोचण्यायोग्य नसते. स्थिर पोर्टवर पुन्हा लिहिणे केवळ बाह्य पोर्टची विस्तृत श्रेणी त्याला जुळली म्हणून प्रत्येक स्थानिक सेवेपर्यंत प्रवेश होत नाही. दोन्ही रचना वेगवेगळ्या दिशांनी अपयशी ठरतात, आणि तुम्ही अपयशाची पद्धत निवडत आहात. जिच्या अपयशासह तुम्ही जगू शकता ती निवडा.

निवडण्यापूर्वी श्रोत्याची यादी करा.

तिसरी अट: बाह्य प्रवेश किती रुंद आहे?

एक निवडलेला पोर्ट प्रकाशित करणे श्रेणी प्रकाशित करण्यापेक्षा अरुंद आहे, आणि दोन्ही सर्व काही स्वीकारण्यापेक्षा अरुंद आहेत. बाह्य रुंदी आणि अंतर्गत भाषांतर स्वतंत्र निवडी आहेत, आणि बहुतेक गोंधळ एक बदलताना दुसरे वर्णन केल्यामुळे होतो.

सामान्य VPN प्रवेशासाठी, रचनेला प्रत्यक्षात आवश्यक असलेले ट्रान्सपोर्ट आणि श्रोता प्रकाशित करा. नंतर आणखी तीन गोष्टी तपासा: राउटरचे प्रभावी मॅपिंग, लक्ष्य होस्टचे स्वतःचे इनपुट नियम, आणि IPv6 श्रोता तीच सेवा प्रकाशित करतो का. एका पत्ता कुटुंबात अरुंद दिसणारा नियम दुसऱ्यात रुंद असू शकतो.

भाषांतरित एंडपॉइंट पूर्ण लिहा: प्रोटोकॉल, बाह्य पोर्ट, अंतर्गत पत्ता, अंतर्गत पोर्ट.

दोन्हीपैकी कोणताही नियम तुम्हाला जे देत नाही

दोन्हीपैकी कोणतीही रचना सेवा दुर्बलतांपासून मुक्त आहे हे सिद्ध करत नाही, आणि कोणतीही उपलब्धतेचे रक्षण करत नाही. पोर्ट मॅपिंग कितीही अरुंद असले तरी प्रमाणीकरण, अद्यतने आणि पुनर्प्राप्ती व्याप्तीत राहतात. अरुंद मॅपिंग पोहोचण्यायोग्य पृष्ठभाग कमी करते; ते श्रोत्याला सुरक्षित करत नाही.

आधीपासून दुसऱ्या कायदेशीर सेवेला आधार देणारा रुंद नियम केवळ चूक नाही, अवलंबित्व आहे. त्याची यादी करा आणि काढण्यापूर्वी त्याच्या मालकामार्फत बदला, अन्यथा बदल सुरक्षा दुरुस्तीमुळे झालेला व्यत्यय वाटेल. तीच सावधानता दुसऱ्या कशावर तरी शांतपणे अवलंबून असलेल्या स्थिर पोर्टवरील पुनर्लेखनालाही लागू होते.

एक्सपोजर विश्लेषण म्हणजे काय कुठपर्यंत पोहोचू शकते याबद्दल, स्क्रीनवरील लेबलबद्दल नाही.

भाषांतरित एंडपॉइंट हातात घेऊन ठरवा

नियमाचा निकाल वाक्य म्हणून लिहा: सार्वजनिक UDP पोर्ट X पत्ता Y पोर्ट Z पर्यंत पोहोचतो. नंतर विचारा की Y वर कोणत्या सेवा Z वर उत्तर देऊ शकतात आणि त्यांचा मालक कोण आहे.

nft list ruleset

उत्तर तुम्ही हेतू असलेला तोच एक श्रोता असल्यास, नियम त्याचे काम करत आहे.

उत्तर अनेक असल्यास, इंटरफेसने त्याला तसे म्हटले किंवा नाही, तुम्ही संपूर्ण होस्टवर फॉर्वर्डिंग निवडले आहे.