एडगार्ड होम आपके LAN पते से वायरगार्ड क्लाइंट्स को उत्तर देता है

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

क्वेरी आती है, उत्तर कहीं और से जाता है

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

जब क्लाइंट का रिसॉल्वर एक कनेक्टेड सॉकेट होता है, जो 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 पढ़ने से तेज़ है, और यह वास्तव में जो चल रहा है उसे दर्शाता है, न कि जो आख़िरी बार सहेजा गया था।

वास्तव में 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 इंटरफ़ेस का नाम बताता है, तो बाइंड परिवर्तन पूरी मरम्मत नहीं है और रूटिंग टेबल अगली चीज़ है जिसे पढ़ना चाहिए।

जो बाइंड सेटिंग ठीक नहीं कर सकता

लिस्नर को पिन करना उस एक्सेस लिस्ट की मरम्मत नहीं करता जो टनल सबनेट को छोड़ देती है, एक फ़ायरवॉल नियम जो क्वेरी की अनुमति देता है लेकिन उत्तर को नहीं, या WireGuard पूल के लिए वापस जाने वाला कोई रूट नहीं। ये स्रोत पते से पहले या बाद में विफल होते हैं, और प्रत्येक का अलग मालिक होता है।

यह भी बदलता नहीं हैजिस अपस्ट्रीम को रिसोल्वर फॉरवर्ड करता हैचाहे रीबाइंडिंग सुरक्षा किसी निजी नाम के लिए निजी उत्तर को अस्वीकार करती है, या क्लाइंट अपने खुद के खोज डोमेन कैसे लागू करता है। ये अलग-अलग नियंत्रण हैं। जब उत्तर स्रोत गलत हो तो बाइंड पता बदलें, और जब यह सही नहीं हो तब कुछ और बदलें।