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 मॅन्युअल कोणत्या फील्ड्स हाताळते आणि कोणती प्रोटोकॉलची आहेत हे नोंदवते, आणि तीच सीमा या अहवालांपैकी बहुतेकांना पूर्ण उत्तर आहे।