wg-quick कनेक्ट पर DNS तोड़ता है: सेटअप त्रुटि पढ़ें

टनल ऊपर आता है, हैंडशेक पूरा होता है, और नाम विश्लेषण रुक जाता है। पीयर कॉन्फ़िगरेशन में कुछ नहीं बदला, क्योंकि DNS पंक्ति कभी पीयर कॉन्फ़िगरेशन का हिस्सा नहीं थी। यह सेटअप सहायक की है, यानी विफलता होस्ट के रिज़ॉल्वर औज़ारों में रहती है, WireGuard की कुंजियों में नहीं।

सहायक द्वारा छापा गया पहला संदेश पढ़ें, आख़िरी नहीं, और अनुपस्थित औज़ार तथा अगम्य सर्वर के बीच का अंतर स्पष्ट हो जाएगा।

DNS पंक्ति सहायक की विशेषता है

मुख्य कॉन्फ़िगरेशन फ़ील्ड पीयर, कुंजियाँ और अनुमत पते बताते हैं। नाम विश्लेषण ऊपर से उस स्क्रिप्ट द्वारा जोड़ा जाता है जो इंटरफ़ेस ऊपर उठाती है, और हर कार्यान्वयन इसे अलग तरह से करता है। डेस्कटॉप क्लाइंट अपनी सेवा से DNS प्रबंधित कर सकता है, वितरण स्क्रिप्ट कई रिज़ॉल्वर औज़ारों में से किसी एक को बुला सकती है, और कंटेनर दोनों में से कुछ भी नहीं कर सकता। कॉन्फ़िगरेशन फ़ाइल आपको नहीं बता सकती कि इनमें से कौन-सा मार्ग चल रहा है।

इसलिए एक कॉन्फ़िगरेशन फ़ाइल प्रोटोकॉल के लिए वैध होकर भी सेटअप के दौरान विफल हो सकती है: विफलता उस हुक की है जिसे प्रोटोकॉल कभी नहीं देखता।

मुख्य कॉन्फ़िगरेशन में विस्तारित फ़ील्ड लिखना और यह अपेक्षा करना कि प्रोटोकॉल औज़ार उसे स्वीकार करेगा, उल्टी दिशा से वही उलझन पैदा करता है। दोनों पार्सर अलग-अलग फ़ाइलें पढ़ते हैं।

कौन-सा चल रहा है, यह जानना पहला निदान कदम है, और यह आमतौर पर आपके लिखे कमांड में दिखता है, कॉन्फ़िगरेशन फ़ाइल में नहीं।

सहायक जो पहली त्रुटि छापता है, उसे पढ़ें

इंटरफ़ेस को सामने लाएँ और आउटपुट क्रम से पढ़ें। अनुपस्थित रिज़ॉल्वर औज़ार, विफल हुक और अगम्य सर्वर सभी उसी कमांड को अलग-अलग जगहों पर रोकते हैं, और हर एक की मरम्मत अलग है।

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

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

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

होस्ट के पास वास्तव में कौन-सा रिज़ॉल्वर है

आधुनिक Linux होस्ट अक्सर स्थानीय स्टब रिज़ॉल्वर चलाते हैं, इसलिए सहायक जो पता स्थापित करता है, वह अनुप्रयोगों द्वारा सीधे नहीं बल्कि उसी स्टब द्वारा उपभोग किया जाता है। उत्पन्न फ़ाइल को हाथ से संपादित करना अगले पुनःकनेक्शन तक काम करता दिख सकता है, जब सहायक उसे फिर से लिख देता है।

वितरण के लिए समर्थित एकीकरण का उपयोग करें और एक ही घटक को रिज़ॉल्वर स्थिति का स्वामी बनने दें। दो स्वामी इंटरफ़ेस पते के दो स्वामियों जैसी ही दौड़ पैदा करते हैं, और लक्षण वह होस्ट है जो हर बदलाव के बाद कुछ मिनट सही विश्लेषण करता है।

आंतरिक नाम अपनी अलग जाँच के योग्य हैं। सार्वजनिक रिज़ॉल्वर सामान्य ब्राउज़िंग बहाल कर सकता है जबकि हर कॉर्पोरेट नाम विफल कर दे, जो टनल के उद्देश्य के विपरीत है। DNS ठीक हो गया है, यह निष्कर्ष निकालने से पहले इच्छित सर्वर से आंतरिक नाम पूछें।

सफ़ाई सेटअप जितनी ही महत्वपूर्ण है

इंटरफ़ेस नीचे उतारें और रिज़ॉल्वर स्थिति फिर से देखें। जो सहायक पिछला कॉन्फ़िगरेशन बहाल करता है, वह होस्ट को उपयोगी छोड़ता है; जो अपने सर्वर पीछे छोड़ देता है, वह अगली विफलता बनाता है, अक्सर घंटों बाद जब टनल बहुत पहले जा चुका होता है।

पुरानी स्थिति खोजने पर आसानी से दिखती है। रिज़ॉल्वर सूची किसी ऐसे इंटरफ़ेस के पते की ओर इशारा कर सकती है जो अब मौजूद नहीं है, और खोज डोमेन आज सुबह छोड़े गए नेटवर्क से बच सकता है। इनमें से कोई भी अगले कनेक्शन को अप्रत्याशित बनाता है, और कोई भी टनल के अपने स्थिति आउटपुट में नहीं दिखता। जाँच में दस सेकंड लगते हैं और अगले व्यक्ति का एक घंटा बचता है।

निदान को मरम्मत से अलग रखें। यदि केवल नाम खोज नहीं, हर गंतव्य विफल हो, तो मार्ग और अग्रेषण संदिग्ध हैं और DNS पंक्ति ध्यान भटकाने वाली है। wg-quick मैनुअल दर्ज करता है कि यह किन फ़ील्डों को संभालता है और कौन-से प्रोटोकॉल के हैं, और वही सीमा इनमें से अधिकांश रिपोर्टों का पूरा उत्तर है।