DNS बदलावों के बाद भी WireGuard पुराना एंडपॉइंट इस्तेमाल करता है

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

नाम एक बार हल होता है, लगातार नहीं

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

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

रिकॉर्ड की तुलना इस्तेमाल हो रहे पते से करें

क्लाइंट जो रिज़ॉल्वर इस्तेमाल करता है उसके ज़रिए दर्ज नाम पूछें, फिर इंटरफ़ेस से पूछें कि उसके पास कौन-सा एंडपॉइंट है। दोनों उत्तर वही तुलना हैं जो इस पृष्ठ के बाकी हिस्से का फ़ैसला करती है:

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

इन पंक्तियों में इस्तेमाल होने वाले show उपकमांड wg(8) मैनुअल में दर्ज हैं। पते के साथ पते की फ़ैमिली भी मिलाएँ, सिर्फ़ पता नहीं, क्योंकि IPv6 प्रविष्टि पा चुका रिकॉर्ड उस रिकॉर्ड से अलग तुलना है जिसका IPv4 पता बदला है। अगर एंडपॉइंट रिकॉर्ड से अलग है तो इंटरफ़ेस पुरानी जानकारी पर चल रहा है और नाम कभी समस्या नहीं था। अगर दोनों मेल खाते हैं और टनल फिर भी विफल होता है, तो प्रोफ़ाइल के बजाय लिसनर और नियमों की ओर जाएँ।

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

इंटरफ़ेस के मैनेजर से पुनः आरंभ करें

एंडपॉइंट के पुराना साबित होने के बाद, इंटरफ़ेस के मालिक उस तंत्र से उसे रीफ़्रेश करें जीवित कॉन्फ़िगरेशन संपादित करने के बजाय। wg-quick से शुरू किए गए इंटरफ़ेस के लिए यह नीचे और ऊपर है, systemd यूनिट के लिए यह पुनः आरंभ है, और मैनेजर के स्वामित्व वाले इंटरफ़ेस के लिए यह उसी मैनेजर में किया गया बदलाव है, क्योंकि रनटाइम संपादन अगली बार लागू होने पर अधिलिखित हो जाता है:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

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

पहले हैंडशेक, फिर डेटा पथ

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

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