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। कधीही न होणारा हँडशेक ही एंडपॉइंटवरील पोहोच किंवा ओळखीची समस्या आहे। दोन्ही मिसळल्यास कोणीही पुन्हा तयार करू न शकणारा अहवाल आणि तीन असंबंधित संपादनांचा बदल लॉग तयार होतो।

नाव, सोडवलेला पत्ता, वापरात असलेला एंडपॉइंट आणि हँडशेक पूर्ण झाला का, हे नोंदवा। ही चार तथ्ये या बिघाडाने वारंवार विचारलेल्या प्रश्नाचे उत्तर देतात, आणि पुढील घटनेची दोन मिनिटांची तपासणी करतात। नावाची देखभाल आणि क्लायंटचा स्वीकार ही वेगळी कामे राहतात: रेकॉर्ड दुरुस्त केल्याने स्वीकार होत नाही, आणि इंटरफेस पुन्हा सुरू केल्याने अजूनही चुकीचा रेकॉर्ड दुरुस्त होत नाही।