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 नोंदीत मूळ tuple, अनुवादित tuple आणि उत्तराची दिशा दिसली पाहिजे। उत्तर नसल्यास पीअर टनेलमधून पाठवत नाही, याचा अर्थ सहसा SNAT नियम लागू झाला नाही किंवा पीअरच्याच फायरवॉलने प्रवाह टाकून दिला।

PostUp नियम पुन्हा लागू करतो हे सिद्ध करण्यासाठी एकदा रीबूट करा, नंतर टनेल थांबवा आणि PreDown ने ते काढले हे तपासा। डिस्कनेक्टनंतर टिकणारे मृत नियम हेच पुढील बदल अनपेक्षितपणे वागण्याचे कारण आहे।

शेवटी, SNAT ची किंमत स्वीकारा। सेवा प्रत्येक विनंती प्रॉक्सीकडून आलेली पाहते, त्यामुळे प्रवेश लॉग, प्रति-क्लायंट दर मर्यादा आणि परवानगी असलेल्या पत्त्यांच्या याद्या आता वापरकर्त्यांमध्ये फरक करत नाहीत। हेअरपिन प्रकरणासाठी प्रॉक्सीच्या LAN वरील क्लायंटसाठी स्वतःचा स्रोत अनुवाद हवा। पीअरला खऱ्या क्लायंट पत्त्यांची गरज असल्यास, पर्याय क्लायंट नेटवर्ककडे परतीचा मार्ग आहे, जो जास्त काम आहे पण माहिती जपतो।