के तपाईंले VPN सबनेटमा पोर्ट फर्वार्डिङमा SNAT लागू गर्नुपर्छ?

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

जवाफ किन अर्को बाटो लिन्छ

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

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

विश्वास गर्न हुने साँघुरो स्रोत नियम

राउटरलाई टाढाको होस्टले जवाफ दिने स्रोत बनाउनुहोस्। यस बिन्यासमा WAN ठेगाना 203.0.113.24 हो, LAN 192.168.88.0/24 हो, राउटरको सुरुङ ठेगाना 172.20.5.1 हो, र सेवाले 172.20.5.40:8443 मा जवाफ दिन्छ। तलको नियम गन्तव्य अनुवादपछिको प्याकेटसँग मेल खान्छ, त्यसैले यसले सार्वजनिकको सट्टा अनुवादित ठेगानाको नाम लिन्छ। यसमा केही पनि क्लाइन्टको ठेगानामा निर्भर छैन, र ठ्याक्कै त्यही मुख्य कुरा हो।

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

त्यो लाइनको हरेक मिलान पुनःलेखनलाई एउटै सुरुङमा एउटै सेवामा सीमित राख्नका लागि छ। इन्टरफेस वा पोर्ट हटाउनुहोस् र समस्याले आवश्यक पारेभन्दा बढी ट्राफिक पुनःलेख्नुहुनेछ, र यसरी लक्षित सुधार अर्को व्यक्तिका लागि रहस्य बन्छ।

कहिले सर्वव्यापी मास्करेड इमानदार विकल्प हो

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

दुवै विकल्प फरक तरिकाले पनि असफल हुन्छन्। हराएको साँघुरो नियमले एउटा सेवा तोड्छ; धेरैसँग मिल्ने फराकिलो मास्करेडले पहिले नै चलिरहेको ट्राफिक, राउटरका आफ्नै बाहिर जाने जडानहरूसमेत, चुपचाप पुनःलेख्न सक्छ।

प्रकाशित गर्नुअघि काउन्टर जाँच्नुहोस्

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

iptables -t nat -L POSTROUTING -v -n --line-numbers

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