क्या आपको 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 के अंदर से हेयरपिन पहुँच एक अलग समस्या है और उसका अपना नियम चाहिए, इसका ज़्यादा चौड़ा संस्करण नहीं।