VPN गेटवे के अपने पते पर LAN सेवा प्रकाशित करें

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

क्लाइंट के दृष्टिकोण से शुरू करें

इस उदाहरण में क्लाइंट VPN पूल 10.62.0.0/24 में बैठता है और पोर्ट 8080 पर 10.62.0.1 से जुड़ता है। वह पता गेटवे का ही है, इसलिए पैकेट किसी अन्य पीयर के बजाय गेटवे के कर्नेल तक पहुँचता है। गेटवे के पीछे LAN 172.21.4.0/24 है। गेटवे के पास 172.21.4.10 है और जो डिवाइस वास्तव में HTTP परोसता है वह 172.21.4.40 है।

किसी अन्य VPN पीयर का पता गेटवे के सेवा पते के साथ बदला नहीं जा सकता। यदि क्लाइंट किसी पीयर के पते से जुड़ रहा है, तो कोई भी गेटवे नियम शामिल ही नहीं है, और यह पूरी यात्रा गलत मामला है।

गंतव्य अनुवाद का दायरा जानबूझकर सीमित करें

संकीर्ण संस्करण एक पोर्ट प्रस्तुत करता है और केवल गंतव्य को फिर से लिखता है। पैकेट अपना प्रोटोकॉल और अपना स्रोत बनाए रखता है, और यही बाकी यात्रा को दिलचस्प बनाता है।

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

प्रोटोकॉल और पोर्ट मानदंडों के बिना नियम विस्तृत संस्करण है: यह जो भी पोर्ट क्लाइंट ने चुना उसे सुरक्षित रखता है और केवल पता बदलता है। जब पूरा होस्ट प्रस्तुत करना हो तो यह वैध है, और जब एक सेवा का इरादा हो तो गलत है। नियम फिर से पढ़ें और इंटरफ़ेस का नाम पुष्टि करें। गलत इंटरफ़ेस पर DNAT नियम किसी से मेल नहीं खाता, जो अनुपस्थित नियम जैसा ही समय-समाप्ति उत्पन्न करता है और डिवाइस को देखने में एक घंटा बर्बाद करता है।

फ़ॉरवर्डिंग सीमा को सहमत होने दें

अनुवाद हेडर बदलता है, अनुमति नहीं देता। डिफ़ॉल्ट ड्रॉप नीति के साथ फ़ॉरवर्ड किए गए प्रवाह को अपनी स्वीकृति चाहिए, और लौटने की दिशा को स्थापित नियम चाहिए जो आपकी नीति में शायद पहले से है।

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

डिवाइस को किसी तरह उत्तर देना ही होगा

अनुवाद के बाद डिवाइस 10.62.0.0/24 में एक स्रोत देखता है। उसका उत्तर उसके डिफ़ॉल्ट गेटवे की ओर जाता है, जो LAN राउटर है, VPN गेटवे नहीं, जब तक कुछ उसे अन्यथा न कहे। दो व्यवस्थाएँ इसे ठीक करती हैं और वे समतुल्य नहीं हैं। डिवाइस पर या LAN राउटर पर एक रूट 10.62.0.0/24 को 172.21.4.10 पर भेजता है और क्लाइंट स्रोत सुरक्षित रखता है। सीमित स्रोत अनुवाद इसके बजाय क्लाइंट को गेटवे के LAN पते के पीछे छिपा देता है।

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

सेवा को जो चाहिए उसके अनुसार चुनें। प्रति-क्लाइंट नीति और अर्थपूर्ण लॉग रूट किया गया रूप चाहते हैं; जिस डिवाइस को रूट नहीं दिया जा सकता, या जिस सेवा को बस LAN पता देखना ही है, वे अनूदित रूप की ओर इशारा करते हैं। एक उत्तर को काम कराने के लिए वैश्विक masquerade नियम की ओर हाथ न बढ़ाएँ। यह हर क्लाइंट को हर गंतव्य से छिपाता है और स्रोत पतों पर निर्भर नीतियों को चुपचाप तोड़ देता है।

गेटवे से ही परीक्षण न करें

गेटवे पर 10.62.0.1 की ओर बनाया गया अनुरोध OUTPUT शृंखला से निकलता है, आने वाली PREROUTING से नहीं। उसकी विफलता या सफलता क्लाइंट की ओर देखने वाले नियम के बारे में कुछ नहीं कहती, और इसी तरह लोग निष्कर्ष निकालते हैं कि काम करने वाला नियम टूटा है।

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

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