WireGuard DNS DNAT: उत्तर का रास्ता चालू रखें

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

10.77.0.0/24 में अधिकृत क्लाइंट wg0 से आते हैं, विज्ञापित पता 10.77.0.1 पूछते हैं और 203.0.113.53 पर रिज़ॉल्वर चाहते हैं — यह उदाहरण लें। अपस्ट्रीम पता दस्तावेज़ीकरण के लिए प्लेसहोल्डर है, चालू सेवा नहीं।

क्वेरी को रीडायरेक्ट करने से केवल उसका गंतव्य बदलता है

PREROUTING में गंतव्य-NAT नियम राउटिंग निर्णय लेने से पहले पते को फिर से लिखता है, इसलिए पैकेट फिर पुराने के बजाय नए गंतव्य की ओर राउट होता है। क्लाइंट का स्रोत पता उस क्रिया से अछूता रहता है। इसीलिए पूरा दिखने वाला नियम भी खामोशी पैदा कर सकता है: अनुरोध अब ऐसे रिज़ॉल्वर तक जाता है जिसने क्लाइंट की निजी रेंज के बारे में कभी नहीं सुना। गेटवे ने एक फ़ील्ड का अनुवाद किया और दूसरी समस्या विरासत में पाई।

दोनों DNS ट्रांसपोर्ट को मेल खाते नियम चाहिए, क्योंकि उत्तर कटने पर क्लाइंट TCP पर लौट आता है।

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

उत्तर का रास्ता अलग निर्णय है

दो व्यवस्थाएँ उत्तर को लौटने देती हैं, और एक को जल्दी चुन लेना एक डिबगिंग सत्र बचाता है। या तो अपस्ट्रीम रिज़ॉल्वर का इस गेटवे से होकर 10.77.0.0/24 तक वापसी रूट है, या गेटवे बाहर निकलते समय स्रोत का अनुवाद करता है ताकि उत्तर ऐसे पते पर पहुँचे जिसे अपस्ट्रीम पहले से जानता है। दोनों काम करते हैं; केवल एक ही अपस्ट्रीम पर आपके नियंत्रण से मेल खाता है।

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

उस अनुवाद को रीडायरेक्ट जितना ही कसकर सीमित करें, वरना नियम उससे मेल खाने वाली किसी भी चीज़ के लिए सामान्य-उद्देश्य NAT बन जाएगा:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

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

नियम काम जितना दिखता है उससे अधिक संकीर्ण लिखें

फ़ॉरवर्डिंग अनुमति उसी दायरे की है। बॉक्स पर हर DNAT कनेक्शन स्वीकार करने के बजाय क्लाइंट-से-रिज़ॉल्वर प्रवाह और वह लौटता ट्रैफ़िक स्वीकार करें जिसे conntrack पहले से पहचानता है। व्यापक स्वीकृति उन पोर्ट फ़ॉरवर्ड को भी अधिकृत करती है जिनका DNS से कोई संबंध नहीं है।

गेटवे का अपना रिज़ॉल्वर अलग कोड पथ है। स्थानीय रूप से जारी क्वेरी OUTPUT से गुज़रती है, इसलिए गेटवे शेल से परीक्षण न PREROUTING नियम को साधता है और न फ़ॉरवर्डिंग नीति को। इसीलिए स्थानीय परीक्षण पास हो सकता है जबकि हर क्लाइंट विफल हो, और उलटा भी उतना ही सामान्य है।

यहाँ कुछ भी पोर्ट 443 पर HTTPS ऊपर DNS या पोर्ट 853 पर TLS ऊपर DNS को कवर नहीं करता, और कुछ भी IPv6 को कवर नहीं करता। IPv6 रिज़ॉल्वर वाला क्लाइंट पूरी व्यवस्था को ख़ुशी से अनदेखा कर देगा।

नई क्वेरी क्या साबित करती है

कनेक्शन ट्रैकिंग पहले के मैपिंग याद रखती है, इसलिए नियम बदलने से पहले भेजी गई क्वेरी पुरानी स्थिति से उत्तर पा सकती है और नए नियम को टूटा हुआ दिखा सकती है। नए स्रोत पोर्ट से शुरू करें और, जहाँ क्लाइंट उत्तर कैश करता है, नए नाम से।

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

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

कुछ भी रीडायरेक्ट करने से पहले पुष्टि करें कि रिज़ॉल्वर उन नामों को जानता है जिनकी आप अपेक्षा करते हैं। ऐसा विकल्प जो सार्वजनिक नामों का उत्तर देता है पर आपके निजी ज़ोन का नहीं एक काम करती lookup को NXDOMAIN में बदल देता है जो टूटी टनल जैसा दिखता है। क्लाइंट पथ शामिल होने से पहले गेटवे से सीधे रिज़ॉल्वर का परीक्षण करें। और iptables एक्सटेंशन संदर्भ उस DNAT और masquerade अर्थ-विधान का दस्तावेज़ीकरण करता है जिस पर ये नियम निर्भर हैं।