Pi-hole v6 ले WireGuard क्लाइन्टका DNS प्रश्नहरू किन बेवास्ता गर्छ
Pi-hole v6 ले कुन VPN क्लाइन्टले 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 फेरि देखा परेपछि पनि रिजोल्भरले उत्तर दिन्छ भनी पुष्टि गर्नुहोस्। अर्को रिबुटसम्म मात्र काम गर्ने प्रश्न पूरा भएको परिवर्तन होइन।