AdGuard Home ले तपाईंको LAN ठेगानाबाट WireGuard क्लाइन्टहरूलाई उत्तर दिन्छ

सुरङ्ग खुलिसकेको छ, फायरवालले पोर्ट 53 अनुमति दिएको छ, AdGuard Home चलिरहेको छ, र नामहरू अझै WireGuard क्लाइन्टका लागि समाधान भएका छैनन्। क्वेरी सामान्यतया आइपुग्छ र उत्तर सामान्यतया जान्छ, त्यसैले रिजोल्भरमा प्याकेट काउन्टरहरू स्वस्थ देखिन्छन् र सेवा निर्दोष जस्तो देखिन्छ। गलत जाने कुरा त्यो उत्तरमा स्रोत ठेगाना हो: यो क्लाइन्टले कहिले पनि सोधेको स्थानीय ठेगानाबाट बाहिर जान्छ, र क्लाइन्टको स्टब रिजोल्भरले यसलाई फिर्ता फ्याँक्छ। AdGuard Home को कन्फिगरेसनमा एउटा सूचीले यसलाई निर्णय गर्छ, र यसको सामान्य डिफल्ट निर्णय कर्नेललाई सुम्पिन्छ।

क्वेरी आइपुग्छ, उत्तर कहीँबाट बाहिर जान्छ

10.6.0.1 लाई यसको रिसोल्वरको रूपमा कन्फिगर गरिएको क्लाइन्टले 10.6.0.1 पोर्ट 53 मा UDP क्वेरी पठाउँछ। त्यो प्याकेट टनेल पार गर्दै होस्टमा पुग्छ, र AdGuard Home यसलाई उत्तर दिन्छ। तारमा, यो जवाफ वास्तवमा नयाँ प्याकेट हो जसको स्रोत ठेगाना होस्टको स्ट्याकले चयन गरेको हुन्छ, क्लाइन्टको अपेक्षाले होइन।

जब क्लाइन्टको रिसोल्वर एक जडित सॉकेट हुन्छ, जुन systemd-resolved, dnsmasq र अधिकांश स्टब रिसोल्वरहरूले प्रयोग गर्छन्, यसले केवल त्यही ठेगानाबाट आएको जवाफ स्वीकार्छ जुन यसले पठाएको थियो। 10.6.0.1 मा पठाइएको क्वेरीको जवाफ 192.168.1.10 बाट आएमा कुनै पनि पार्सिङ हुनु अघि नै त्यसलाई ड्रप गरिन्छ। रिसोल्वर सफल जवाफको लग गर्छ, क्लाइन्ट समय समाप्त भएको लग गर्छ, र दुवै सत्य कुरा बताइरहेका छन्।

त्यसोभए काउन्टरहरू झूट बोलिरहेका छैनन् र ग्राहक पनि होइन। तपाईंलाई चाहिने प्रमाण तीन ठाउँमा छन्, यस क्रममा: श्रोतालाई बाँधिएको ठेगाना, कर्नेलले ग्राहकतिर फर्किन प्रयोग गर्ने मार्ग, र वास्तविक प्रतिक्रिया प्याकेटमा स्रोत ठेगाना।

कर्नेलले प्रतिक्रिया स्रोत कसरी छनौट गर्छ

एउटा UDP सॉकेट0.0.0.0सँग बाँधिएको हुँदा यसको आफ्नै स्रोत ठेगाना हुँदैन, त्यसैले प्रत्येक बाहिर जाने प्रतिक्रियाले गन्तव्यको लागि मार्ग खोजी उत्पन्न गर्छ। त्यसपछि कर्नेलले मार्गबाट स्रोत लिन्छ: मार्गद्वारा पिन गरिएको ठेगाना, वा बाहिर जाने इन्टरफेसको प्राथमिक ठेगाना। क्वेरीको गन्तव्य ठेगानाबारे केही पनि सम्झनामा रहँदैन।

एकल-होम्ड होस्टमा यो अदृश्य हुन्छ, किनभने त्यहाँ केवल एक मात्र सम्भावित उत्तर हुन्छ। एक मेशिनमा LAN ठेगाना, WireGuard ठेगाना, र व्यवस्थापन ठेगाना भएको अवस्थामा, धेरै उत्तर सम्भावित हुन्छन्, र विजेता त्यस समयमा राउटिङ टेबुलमा निर्भर हुन्छ। एक अतिरिक्त मार्ग थप्नुहोस्, एउटै इन्टरफेसमा दोस्रो ठेगाना थप्नुहोस्, रिजोल्भरको अगाडि NAT रिडिरेक्ट चलाउनुहोस्, वा AdGuard लाई आफ्नै नेमस्पेससहित कन्टेनरमा चलाउनुहोस्, र चयन गरिएको स्रोत ग्राहकले सोधेको उत्तरबाट फरक पर्न सक्छ।

ss -lunp | grep :53कुन खेलमा तपाईं हुनुहुन्छ भन्ने देखाउँछ।0.0.0.0:53मा लिस्नर वाइल्डकार्ड केस हो;10.6.0.1:53मा लिस्नरले पहिले नै उत्तर पिन गरिसकेको छ। सॉकेट पढ्नु YAML पढ्नुभन्दा छिटो हुन्छ, र यसले पछिल्लो save गरिएको हुँदैन भन्दा वास्तवमा चलिरहेको कुरा दर्शाउँछ।

वास्तवमा bind_hosts ले के नियन्त्रण गर्छ

AdGuard Home कोdns.bind_hostsDNS सुन्नेले प्रयोग गर्ने स्थानीय ठेगानाहरूको सूची हो। पठाइएको पूर्वनिर्धारित मान वाइल्डकार्ड हो, जसको अर्थ हरेक स्थानीय ठेगानामा स्वीकार गर्नु र जवाफ अनुसार स्रोतको छनोट कर्नेललाई गर्न दिनु हो। वाइल्डकार्डलाई ग्राहकले सोध्ने ठेगानाले प्रतिस्थापन गर्दा सॉकेट परिवर्तन हुन्छ, र प्रत्येक जवाफमा स्रोत ठेगानासँग पनि परिवर्तन हुन्छ।

सूचीले एकभन्दा बढी प्रविष्टिहरू समावेश गर्न सक्छ, जुन दुई नेटवर्क सेवा दिने रिजोल्भरमा महत्व राख्छ।10.6.0.1र192.168.1.10सूचीबद्ध गर्दा दुई बाँधिएको सॉकेटहरू हुन्छन्, र तीमध्ये कुनै एकमा आउने प्रश्न त्यसमा आएको ठेगानाबाट उत्तर दिइन्छ। यो व्यवहार धेरैले मान्ने वाइल्डकार्डले पहिले नै प्रदान गर्छ भन्ने हो।

YAML साधारण छ, र यसको ठेगाना तपाईंका टनेल ग्राहकहरूले प्रयोग गर्न भनिएको हो, होस्टको मुख्य ठेगाना होइन:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

किन एउटै रिजोल्भरको दुई स्थापना फरक देखाउँछन्

यस सन्दर्भमा, प्लगइन-प्रबन्धित भन्नाले रिजोल्भर अर्को प्याकेजद्वारा स्थापना गरिएको र अनुगमन गरिएको छ भन्ने जनाउँछ: एक राउटर फर्मवेयर प्याकेज, NAS प्याकेज, वा हरेक-घर स्वचालन एड-अन। त्यो प्याकेज सामान्यतया AdGuard Home को YAML को आफ्नो प्रति पठाउँछ र आफ्नै तालिकाको अनुसार प्रक्रिया पुनः सुरु गर्दछ, जबकि स्वतन्त्र उदाहरण भनेको तपाईंले आफैंले कन्फिगर गर्ने विक्रेता बाइनरी वा कन्टेनर हो। जे भए पनि तपाईं दुई स्वतन्त्र प्रक्रियाहरू हेर्दै हुनुहुन्छ जसको अलग कन्फिगरेसन फाइलहरू र अलग बाइन्ड विकल्पहरू हुन्छन्, यद्यपि दुबै एउटै अपस्ट्रीम सूची र एउटै फिल्टर सूची पढ्छन्। एउटाले विशेष टनेल ठेगाना बाइन्ड गर्न सक्छ भने अर्काले वाइल्डकार्ड उत्तराधिकारमा पाउँछ, र वेब इन्टरफेस दुबै पक्षबाट समान देखिन्छ।

त्यसैले 'माईग्रेशनअघि एउटै रिजोल्भरले काम गरेको' भन्ने कुराले वर्तमान बाइन्डिङको बारेमा केही प्रमाणित गर्दैन। सॉकेट जाँच गर्नुहोस्, त्यसपछि कन्फिगरेसन फाइल जाँच गर्नुहोस् जुन चलिरहेको प्रक्रिया वास्तवमा लोड गरेको छ। अर्को डाइरेक्टरीमा रहेको पुरानो प्रतिलिपि एडिटको असर नभएको जस्तो देखिनु सामान्य कारण हो।

यसलाई पिन गर्नुहोस्, त्यसपछि टनेल साइडबाट परीक्षण गर्नुहोस्

परिवर्तन गर्नुहोस्bind_hostsटनेल ठेगानामा, सेवा पुनः सुरु गर्नुहोस्, र सॉकेट सरेको सुनिश्चित गर्नुहोस्:ss -lunp | grep :53अब देखाउनु पर्छ10.6.0.1:53र कुनै वाइल्डकार्ड इन्ट्री छैन। यदि अझै0.0.0.0देखिन्छ भने,चलिरहेको प्रक्रिया तपाईंले सम्पादन गरेको फाइल पढिरहेको छैन।

त्यसपछि क्लाइन्टबाट परीक्षण गर्नुहोस्, किनभने त्यो मात्र महत्वपूर्ण पक्ष हो।dig @10.6.0.1 example.comसँगको क्वेरीले प्रयोगकर्ताले गर्ने पथ अभ्यास गर्छ, र होस्टमा क्याप्चरलेtcpdump -ni wg0 udp port 53तारमा जवाफको स्रोत ठेगाना देखाउँछ। यसलाई ग्राहकको रेजोल्भर सेटिङमा रहेको ठेगानासँग तुलना गर्नुहोस्; जब ती बराबर हुन्छन्, टाइमआउट रहस्य हुन बन्द हुन्छ।

ip route get 10.6.0.2बाँकी कुनै पनि अनौठोपनाको व्याख्या गर्छ, किनभने यसले इन्टरफेस र स्रोतलाई प्रिन्ट गर्छ जुन होस्टले ग्राहकतर्फ प्रयोग गर्ने थियो। यदि त्यो आउटपुटले LAN इन्टरफेसको नाम दिन्छ भने, बाइन्ड परिवर्तन मात्र सम्पूर्ण समाधान होइन र रूटिङ टेबल नै अर्को कुरा पढ्नुपर्ने हुन्छ।

बाइन्ड सेटिङले के ठीक गर्न सक्दैन

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

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