अॅडगार्ड होम आपल्या LAN पत्त्या वरून वायरगार्ड क्लायंट्सना उत्तर देते

सुरंग तयार आहे, फायरवॉल पोर्ट 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 ला त्याच्या स्वत:च्या namespace सह कंटेनरमध्ये चालवा, आणि निवडलेले स्त्रोत क्लायंटने विचारलेल्या सूत्रापेक्षा वेगळे असू शकते.

ss -lunp | grep :53कोणत्या गेममध्ये आपण आहात ते दर्शवते.0.0.0.0:53वरील झोपा वाचक ही वाइल्डकार्ड केस आहे;10.6.0.1:53वरील झोपा वाचकाने उत्तर आधीच पिन केले आहे. सॉकेट वाचणे YAML वाचण्यापेक्षा वेगवान आहे, आणि ते जे प्रत्यक्षात चालत आहे ते दर्शवते, शेवटचे जतन केलेले नाही.

bind_hosts खरोखर काय नियंत्रित करते

AdGuard Home चेdns.bind_hostsही DNS श्रोते वापरत असलेली स्थानिक पत्त्यांची यादी आहे. शिप केलेली डीफॉल्ट वाइल्डकार्ड आहे, ज्याचा अर्थ प्रत्येक स्थानिक पत्यावर स्वीकारा आणि प्रत्युत्तरानुसार स्रोत कर्नल निवडेल. वाइल्डकार्डला क्लायंट्स जे पत्ता क्वेरी करतात त्याने बदलल्यास सॉकेट बदलते, आणि प्रत्येक उत्तरावर स्रोत पत्ता बदलतो.

ही यादी एकापेक्षा जास्त नोंदी घेतो, जे दोन नेटवर्क्सना सेवा देणाऱ्या रिझॉल्व्हरसाठी महत्त्वाचे आहे.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 पूलकडे परत जाणारा गहाळ राऊट दुरुस्त होत नाही. हे स्त्रोत पत्त्यापेक्षा आधी किंवा नंतर अयशस्वी होतात, आणि प्रत्येकाचे वेगळे मालक असते.

हे देखील बदलत नाहीरिझॉल्वर कोणत्या अपस्ट्रीमला फॉरवर्ड करतो, पुनर्बाईंड संरक्षण खाजगी नावासाठी खाजगी उत्तर नाकारते की नाही, किंवा क्लायंट आपली स्वतःची शोध डोमेन कशी लागू करतो. हे वेगळे नियंत्रण आहेत. उत्तर स्रोत चुकीचा असल्यास बाइंड पत्ता बदला, आणि तो नाही असल्यास काहीतरी इतर बदला.