WireGuard DNS DNAT: उत्तरको बाटो कार्यरत राख्नुहोस्

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

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

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

सम्बन्धित लेखहरू