Pi-hole v6 WireGuard क्लायंटच्या DNS क्वेरी का दुर्लक्षित करते

Pi-hole v6 पोर्ट 53 वर DNS क्वेरी घेते आणि नंतर आलेल्या पॅकेटला उत्तर देण्याची परवानगी आहे का हे ठरवते। WireGuard होस्टवर हा दुसरा निर्णय सामान्यतः क्लायंटला टाइमआउट का होतो याचे कारण असतो, तर रिझॉल्व्हर LAN वरून निरोगी दिसतो। पोर्ट उघडा आहे, FTL चालू आहे, तरीही 10.90.0.1 वरून काहीही परत येत नाही। उत्तर निघण्यापूर्वी तीन गोष्टी परस्परांवर परिणाम करतात: dns.interface, dns.listeningMode आणि दोन्हींसमोरील फायरवॉल।

ऐकणारा सॉकेट कोणाला उत्तर मिळेल हे ठरवत नाही

FTL पोर्ट 53 वर UDP आणि TCP श्रोते उघडते। डीफॉल्ट कॉन्फिगरेशनमध्ये सॉकेट बहुतेक वेळा wildcard असते, म्हणून ss -lunp | grep :53 VPN क्लायंटना सेवा मिळत असो वा नसो, 0.0.0.0:53 आणि [::]:53 दाखवते। wildcard सॉकेट पॅकेट स्वीकारते, नंतर FTL उत्तर देण्यापूर्वी आपले इंटरफेस आणि स्रोत नियम लागू करते। म्हणूनच "पोर्ट ऐकत आहे" हे विधान टनेल क्लायंटबद्दल फारच कमी सिद्ध करते।

तुम्ही सक्रिय मानता त्या फाइलऐवजी चालू कॉन्फिगरेशन वाचा। pihole-FTL --config dns.interface आणि pihole-FTL --config dns.listeningMode प्रभावी मूल्ये छापतात, आणि कंटेनर, पर्यावरण चल किंवा डिप्लॉयमेंट मॅनेजर ते सेटिंग ठेवत असेल तर ती होस्ट फाइलपेक्षा वेगळी असू शकतात। Pi-hole FTL कॉन्फिगरेशन संदर्भ मोड आणि त्यातील कोणता इंटरफेसवर अवलंबून आहे याची यादी करतो।

LOCAL कोणते सबनेट विचारते, SINGLE कोणता इंटरफेस विचारते

LOCAL, डीफॉल्ट, ज्या क्वेरींचा स्रोत पत्ता होस्टच्या एका इंटरफेसवर कॉन्फिगर केलेल्या सबनेटमध्ये येतो त्यांना उत्तर देते। 10.90.0.1/24 असलेले साधे wg0 ही चाचणी उत्तीर्ण होते, कारण 10.90.0.2 वरील क्लायंट टनेल सबनेटमध्ये आहे। पीअरच्या पलीकडे राउट केलेला क्लायंट, किंवा वेगळ्या प्रीफिक्समध्ये NAT मागे लपलेला क्लायंट, पॅकेट wg0 वर आले तरी ती उत्तीर्ण होत नाही, आणि लॉगमध्ये एकही क्वेरी दिसत नाही।

SINGLE प्रश्न बदलते। ते dns.interface मध्ये नामनिर्देशित इंटरफेसवर येणाऱ्या क्वेरी लूपबॅकसह स्वीकारते आणि स्रोत सबनेट दुर्लक्षित करते। साखळीबद्ध किंवा राउट केलेल्या VPN टोपोलॉजीमध्ये टिकणारा मोड हाच आहे। दोन्ही की एकत्र सेट करा, कारण नामनिर्देशित इंटरफेसशिवाय मोड पूर्ण सूचना नाही:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND सॉकेट बदलते आणि त्याला किंमत आहे

BIND wildcard सॉकेट फिल्टर करत नाही; ते पोर्ट 53 फक्त नामनिर्देशित इंटरफेसवर असलेल्या पत्त्यांशी जोडते, त्यामुळे कर्नेल इतरत्र येणारे पॅकेट नाकारते। ते SINGLE पेक्षा कडक आहे आणि त्याचा समानार्थी नाही। किंमत बूटच्या वेळी दिसते: FTL सुरू होताना wg0 वर नसेल, तर जोडण्यासाठी पत्ता नसू शकतो, आणि इंटरफेस दिसून FTL पुन्हा सुरू होईपर्यंत रिझॉल्व्हर श्रोत्याशिवाय चालू शकतो।

स्टार्टअप क्रम तुम्ही नियंत्रित करता तेव्हा BIND निवडा, उदाहरणार्थ WireGuard इंटरफेसनंतर क्रमबद्ध systemd युनिट, आणि कर्नेलने FTL पाहण्यापूर्वी भटकती पॅकेट टाकून द्यावीत असे वाटत असेल तेव्हा। टनेल येते-जाते तेव्हा, किंवा FTL नंतर सुरू होणारे साधन इंटरफेस तयार करते तेव्हा SINGLE निवडा।

फायरवॉल हे दुसरे प्रवेशद्वार आहे

योग्य FTL मोडही होस्ट फायरवॉलने wg0 वर पोर्ट 53 टाकून दिल्यास अयशस्वी होतो। दोन्ही प्रोटोकॉलसाठी VPN स्रोत श्रेणीला परवानगी द्या आणि इंटरनेट बाजू बंद ठेवा। nftables मध्ये, inet filter तक्त्यातील विद्यमान input साखळीसह, नियम असे दिसतात:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

टनेल IPv6 वाहत असेल तर जुळणारे IPv6 नियम जोडा, आणि ते साखळीच्या drop धोरणापूर्वी ठेवा। होस्ट ufw किंवा firewalld वापरत असेल, तर साधने मिसळण्याऐवजी त्याच व्यवस्थापकात तोच जुळणी व्यक्त करा। इंटरनेट राउटरवरून पोर्ट 53 पुढे पाठवू नका; क्लायंटने टनेलमार्गे रिझॉल्व्हरच्या VPN पत्त्यावर पोहोचावे।

दोन मार्ग वेगळे राहतात। क्लायंट क्वेरी FTL वर संपतात। FTL च्या स्वतःच्या अपस्ट्रीम शोध होस्टच्या राउटिंग तक्त्यानुसार बाहेर पडतात, जे टनेल वापरू शकते किंवा नाही, म्हणून उत्तर देणारा पण उपयुक्त काहीही परत न देणारा रिझॉल्व्हर ही अपस्ट्रीम समस्या आहे। वेब अ‍ॅडमिन आणि API स्वतःच्या पोर्टवर ऐकतात आणि त्यांना स्वतःचे बंधन हवे।

उत्तर आणि नकार तपासा

VPN क्लायंटवरून, दोन्ही प्रोटोकॉलवर रिझॉल्व्हरचा पत्ता विचारा: dig @10.90.0.1 example.com आणि dig +tcp @10.90.0.1 example.com। नंतर अ‍ॅडमिन इंटरफेसमधील क्वेरी लॉग तपासून FTL ने क्वेरी नोंदवली आहे याची खात्री करा। लॉग नोंदीशिवाय क्लायंट टाइमआउट फायरवॉल किंवा इंटरफेस फिल्टरकडे निर्देश करतो; उत्तराशिवाय लॉग नोंद अपस्ट्रीम निवारणाकडे निर्देश करते।

VPN बाहेरील होस्टवरून नकारात्मक मार्ग तपासा। dig @10.90.0.1 example.com टाइमआउट व्हायला हवे, आणि ss -lunp रिझॉल्व्हरवर पोर्ट 53 सार्वजनिक पत्त्याशी जोडलेला दिसू नये। सेवा एकदा पुन्हा सुरू करा, नंतर होस्ट रीबूट करा आणि wg0 पुन्हा दिसल्यानंतरही रिझॉल्व्हर उत्तर देतो याची खात्री करा। फक्त पुढील रीबूटपर्यंत चालणारी क्वेरी पूर्ण झालेला बदल नाही।