NAT के पीछे मौजूद WireGuard पीयर तक पोर्ट फ़ॉरवर्डिंग: DNAT और SNAT

एक ब्राउज़र https://203.0.113.10:8443 का अनुरोध करता है, प्रॉक्सी कनेक्शन स्वीकार करता है, और WireGuard पीयर पर चल रही सेवा कभी जवाब नहीं देती। DNAT नियम अपना काम कर रहा है; विफल होने वाला हिस्सा जवाब है। पैकेट को दोनों अनुवादों से गुज़ारें और छूटा हुआ नियम स्पष्ट हो जाता है। सुधार सही हुक में एक और NAT कथन है, नई टनल नहीं।

एक अनुरोध को शुरू से अंत तक देखें

अनुरोध प्रॉक्सी के सार्वजनिक इंटरफ़ेस पर पहुँचता है, जिसमें स्रोत क्लाइंट का सार्वजनिक पता और गंतव्य प्रॉक्सी का पता होता है। nat PREROUTING में DNAT नियम गंतव्य को पीयर के टनल पते 10.90.0.2 पर फिर से लिखता है। फिर रूटिंग निर्णय पैकेट को wg0 से बाहर भेजता है, और फ़ॉरवर्ड पथ पूरा हो जाता है।

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

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

वापसी अनुवाद जोड़ें

फ़ॉरवर्ड किए गए प्रवाह का स्रोत फिर से लिखें पीयर की ओर जाने से पहले प्रॉक्सी के टनल पते पर। फिर सेवा 10.90.0.1 को जवाब देती है, प्रॉक्सी उसे प्राप्त करता है, और पैकेट के क्लाइंट के पास लौटने से पहले कनेक्शन ट्रैकिंग दोनों अनुवादों को उलट देती है।

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

POSTROUTING नियम जानबूझकर संकीर्ण है: यह अनुवादित गंतव्य और टनल इंटरफ़ेस से मेल खाता है, इसलिए wg0 से संयोगवश निकलने वाले असंबंधित ट्रैफ़िक को फिर से नहीं लिखता। एक व्यापक masquerade नियम भी क्लाइंट का पता छिपाता, लेकिन यह हर प्रवाह के लिए ऐसा करता और NAT तालिका का ऑडिट कठिन बना देता।

नियमों को वहाँ रखें जहाँ टनल मौजूद है

टनल पते या इंटरफ़ेस का संदर्भ देने वाले नियम wg-quick द्वारा उसे कॉन्फ़िगर करने के बाद चलने चाहिए। इंटरफ़ेस PreUp से पहले बनता है, लेकिन पते, MTU, DNS और रूट बाद में लागू होते हैं, और PostUp तब चलता है जब यह सब जगह पर हो। जोड़ PostUp में और हटाना PreDown में रखें।

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

हटाना जोड़ से टोकन दर टोकन मेल खाना चाहिए, जिसमें multiport और इंटरफ़ेस की मेल भी शामिल है। एक मेल में भिन्न हटाना कुछ भी नहीं हटाता, और अगला पुनःकनेक्शन नियम की दूसरी प्रति जोड़ देता है। कुछ पुनःकनेक्शन के बाद तालिका में ऐसी प्रतियाँ होती हैं जिन्हें कॉन्फ़िगरेशन पंक्ति से जोड़ना कठिन है।

परिणाम iptables -t nat -S से पुनःकनेक्शन के बाद जाँचें। अगर वही नियम दो बार दिखे, तो PreDown पंक्ति मेल नहीं खाती और सफ़ाई चुपचाप विफल हो जाती है।

फ़ॉरवर्डिंग, फ़िल्टरिंग और दूसरा NAT

IPv4 फ़ॉरवर्डिंग स्थायी रूप से सक्षम करें, फिर फ़िल्टर तालिका में फ़ॉरवर्ड किए गए प्रवाह को अनुमति दें। DNAT FORWARD श्रृंखला से पहले होता है, इसलिए फ़िल्टर नियम सार्वजनिक पते के बजाय अनुवादित गंतव्य से मेल खाता है। अगर UFW फ़ायरवॉल संभालता है, तो अनुमति को रूट नियम के रूप में व्यक्त करें; साधारण होस्ट नियम फ़ॉरवर्ड किए गए ट्रैफ़िक को कवर नहीं करता।

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

NAT VPS पर प्रदाता सार्वजनिक पोर्ट को निजी पते पर मैप करता है। मैपिंग वही पोर्ट होनी चाहिए जिसकी आप घोषणा करते हैं, और असंगति टूटी टनल जैसी ही दिखती है। WireGuard कॉन्फ़िगरेशन बदलने से पहले प्रदाता की मैपिंग की पुष्टि करें।

वापसी पथ जाँचें और लागत स्वीकारें

ऐसे नेटवर्क से कनेक्ट करें जो प्रॉक्सी का LAN न हो, फिर कनेक्शन खुला रहने पर अनुवाद जोड़ी की जाँच करें:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

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

यह साबित करने के लिए एक बार रीबूट करें कि PostUp नियम फिर से लागू करता है, फिर टनल रोकें और पुष्टि करें कि PreDown ने उन्हें हटा दिया। डिस्कनेक्ट के बाद बचे मृत नियम ही इस बात का कारण हैं कि बाद का बदलाव अप्रत्याशित व्यवहार करता है।

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