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 0.0.0.0:53 और [::]:53 दिखाता है, चाहे VPN क्लायंट को सेवा मिले या न मिले। 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 के देखने से पहले भटके पैकेट गिरा दे। SINGLE तब चुनें जब टनल आता-जाता रहता है, या जब इंटरफ़ेस कोई ऐसा उपकरण बनाता है जो FTL के बाद शुरू होता है।

फ़ायरवॉल दूसरा द्वार है

सही 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 के फिर दिखने के बाद भी रिज़ॉल्वर उत्तर देता है। जो प्रश्न केवल अगले रीबूट तक काम करे, वह पूरा हुआ परिवर्तन नहीं है।