WireGuard ले एकै समयमा नयाँ ह्यान्डशेक र ठेगाना नभएको अवस्था दुवै राख्न सक्छ, र त्यो अवस्था विरोधाभासी होइन, सुसंगत छ। ह्यान्डशेक पियरको घटना हो, ठेगाना इन्टरफेसको हो, र प्याकेट कुन अपलिङ्कबाट बाहिरिन्छ भन्ने रुटले निर्धारण गर्छ। तीन तह, तीन मालिक, र बाँकी दुई स्वस्थ देखिँदा पनि प्रत्येक बिग्रन सक्छ।

तिनलाई एउटै स्थिति ठानेर पढ्नु नै दुई मिनेटको निदानलाई सेवा पुनःसुरु गर्दै बिताउने पूरा दिउँसोमा बदल्छ।

ह्यान्डशेक पियरको घटना हो, ठेगाना दिने घटना होइन

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

त्यसैले wg show एप्लिकेसनबाट एउटै प्याकेट लिन नसक्ने इन्टरफेसमा केही सेकेन्ड पुरानो ह्यान्डशेक रिपोर्ट गर्न सक्छ।

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

ObservationWhich layer it belongs toWrong conclusion it invites
Handshake a few seconds oldPeer and keysThe tunnel is usable for application traffic
Address present on wg0Interface configurationTraffic actually egresses through it
Route points at wg0Forwarding tableThe outer packet uses the intended uplink

इन्टरफेसको ठेगानाको आफ्नै मालिक हुन्छ

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

एउटै इन्टरफेसमा दुई मालिक हुनु चिरपरिचित बिग्र हो। एउटै यन्त्रमा सहायक र डेस्कटप नेटवर्क म्यानेजर सुरु गर्दा एउटाले अर्कोले भर्खर कन्फिगर गरेको कुरा हटाउने दौड बन्छ, र अन्त्य बिन्दु त्यो सबै बेला जवाफ दिइरहन्छ।

एउटा मालिक छान्नुहोस् र अर्को उपकरणलाई व्यवस्थापन गर्नुको सट्टा अवलोकन गर्न दिनुहोस्। त्यो निर्णय लेख्न लायक छ, किनकि लक्षण हप्ताहरूपछि देखिन्छ र ठेगाना अचानक हराएको जस्तो लाग्छ।

अपलिङ्क रुटले छान्छ, इन्टरफेसले होइन

wg0 तिर देखाउने आन्तरिक रुटले ट्राफिक टनेलमा प्रवेश गर्छ भनी निर्धारण गर्छ। अलग निर्णयले इन्क्रिप्ट गरिएका बाह्य प्याकेट पियरतिर पठाउँछ, र धेरै अपलिङ्क भएको होस्टमा त्यो निर्णय फर्वार्डिङ तालिका र नीति नियमबाट आउँछ। Wi-Fi रोमिङले आन्तरिक ठेगाना नछोई बाह्य बाटो बदल्न सक्छ।

त्यसैले चल्ने टनेल र पुग्न नसकिने पियर सुसंगत अवस्था हुन्, र सही पियर तथा बिग्रेको आन्तरिक रुट पनि त्यस्तै। तीनै अवलोकन एकैसाथ, एउटै क्षणमा लिनुपर्छ, नत्र तुलना निरर्थक हुन्छ।

तीन अवस्थाको एउटै पासमा तुलना गर्नुहोस्

पढ्न मात्र मिल्ने तीन आदेशले तीन प्रश्नको जवाफ यस्तो क्रममा दिन्छन् जसले बिग्र छिटो अलग गर्छ। तिनलाई बीचमा केही नबदली चलाउनुहोस्।

ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transfer

पहिलोले इन्टरफेसमा ठेगाना छ कि छैन देखाउँछ, र दोस्रोले कुनै निश्चित गन्तव्यले अहिले कुन यन्त्र प्रयोग गर्नेछ देखाउँछ। तेस्रोले अन्तिम ह्यान्डशेकको समय र बाइट काउन्टर रिपोर्ट गर्छ, र तीनमध्ये स्थानीय होस्टको सट्टा पियरको वर्णन गर्ने त्यही एउटा मात्र हो।

टाइमस्ट्याम्पसँगै काउन्टर पनि पढ्नुहोस्। स्थानान्तरण समथर रहँदा निरन्तर नवीकरण हुने ह्यान्डशेक भन्नाले पियर जवाफ दिइरहेको छ तर उपयोगी केही पार भइरहेको छैन, जसले कुञ्जीतिर होइन, रुटिङ वा ACL तिर देखाउँछ। ठेगाना हुँदा टाइमस्ट्याम्प अगाडि बढ्न छाड्छ भने त्यसले उल्टै माथितिर देखाउँछ। दुवै पठन आउटपुटको एउटै लाइनबाट आउँछन्, र ह्यान्डशेक छ कि छैन मात्र जाँच्नुभयो भने कुनै पनि देखिँदैन।

गलत भएको निश्चित अवस्था सुधार्नुहोस्, त्यसपछि टनेल होइन, एप्लिकेसन फेरि परीक्षण गर्नुहोस्। नयाँ ह्यान्डशेक पियरबारे प्रमाण हो, र पियरबारे प्रमाण तपाईंको ब्राउजरको अर्को अनुरोधले ठेगाना, रुट र चल्ने अपलिङ्क भेट्नेछ भन्ने प्रमाण होइन। wg-quick निर्देशिका ले तीमध्ये कुन सहायकले सेट गर्छ र कुन प्रोटोकलको हो स्पष्ट भन्छ।

सम्बन्धित लेखहरू