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। कहिल्यै नहुने ह्यान्डशेक इन्डपोइन्टमा पुग्ने क्षमता वा पहिचानको समस्या हो। दुवै मिसाउँदा कसैले पनि पुनः उत्पादन गर्न नसक्ने प्रतिवेदन र तीन असम्बन्धित सम्पादन भएको परिवर्तन लग बन्छ।

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