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 अर्थशास्त्राचे दस्तऐवजीकरण करते।

संबंधित लेख