WireGuard निष्क्रियतापछि असफल हुन्छ: पहिले दिशा जाँच्नुहोस्

कुनै पनि सेटिङ परिवर्तनअघि चार प्रश्न आउँछन्: क्लाइन्ट सक्रिय हुँदा त्यही स्रोत चल्छ कि, निष्क्रिय अवधि कति लामो थियो, यन्त्र सुत्यो कि नेटवर्क बदल्यो, र असफलता केवल विपक्षी पक्षले सुरु गर्ने ट्राफिकमा मात्र देखिन्छ कि। उत्तरहरूले म्याद सकिएको NAT म्यापिङलाई सुतेको रेडियो र पुरानो एपबाट छुट्याउँछन्। keepalive को कुनै सान्दर्भिकता छ कि भनेर पनि तिनीहरू बताउँछन्। दिशाबाट सुरु गर्नुहोस्, किनकि यसलाई एउटा आदेश लाग्छ र सम्भावित कारणको आधा हटाउँछ।

कुन दिशा असफल हुन्छ?

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

शान्त अवधि कति लामो थियो र यन्त्र सुत्यो कि यसै बीच अर्को नेटवर्कमा गयो, टिप्नुहोस्। यी दुई तथ्यले कुनै पनि सेटिङअघि निदान बदल्छन्।

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

शान्त अवधिअघि र पछि ती तीन चलाउनुहोस्, किनकि प्रत्येकले प्रश्नको फरक भागको जवाफ दिन्छ। नहल्लेको handshake समयछापले दुवै पक्ष बोल्न छोडेको बताउँछ, जबकि बदलिएको अन्त्य बिन्दु ले म्यापिङ मरेको होइन, सरेको बताउँछ। स्थानान्तरण गणकहरूले केही पुग्यो कि भनेर देखाउँछन्, र यही पुरानो म्यापिङ र मौन एपबीचको फरक हो। दुवै समयमा अंकहरू लेख्नुहोस्, किनकि तुलना नै प्रमाण हो।

निद्रा, रेडियो र एपको अवस्था

फोन वा ल्यापटपमा सुतेको यन्त्रले नेटवर्क पहुँच पूरै गुमाएको हुन सक्छ, र keepalive ले बन्द रेडियो फर्काउन सक्दैन वा पूरा नभएको captive portal पूरा गर्न सक्दैन। मोबाइल प्लेटफर्महरू नीतिअनुसार पृष्ठभूमि काम स्थगित गर्छन्, त्यसैले आवधिक ट्राफिक चलिरहन्छ कि भन्ने प्लेटफर्म र एपले त्यससँग के सहमति गरेको छ त्यसमा निर्भर छ। क्यास गरिएको जडान तेस्रो केस र सबैभन्दा भ्रमित पार्ने हो, किनकि टनेल फर्किनु र एपले त्यसमा फेरि जोडिनु एउटै होइन।

निष्क्रिय अवधिपछि खुला रहेको ट्याबमा भर नगरी एप फेरि खोल्नुहोस्। जहाँ पुरानो सत्र असफल भयो त्यहाँ नयाँ अनुरोध सफल भयो भने टनेल कहिल्यै समस्या थिएन।

keepalive ले वास्तवमा के गर्छ

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

अधिकांश निष्क्रिय अवधि असफलता होइनन्। पाँच मिनेट मौनतापछि फेरि जोडिने टनेल ठीक व्यवहार गर्छ, र समस्या केवल त्यो अवस्था हो जहाँ विपक्षी पक्षबाट केही आउनुपर्ने थियो।

पहिले असफल हुने अन्तराल पर्खनुहोस्

एउटा समर्थित परिवर्तन गर्नुहोस्, त्यसपछि त्यो स्रोत फेरि जाँच्नुअघि त्यही निष्क्रिय अवधि बित्न दिनुहोस्। पर्खनु परीक्षणको भाग हो, औपचारिकता होइन। फेरि जोडिएपछिको तत्काल सफलताले लामो निष्क्रियताको लक्षणबारे केही भन्दैन, किनकि फेरि जोडिनु नै अवस्था रिसेट गर्ने घटना हो। समस्या सक्रिय प्रयोगमा पनि देखिन्छ भने थप आवधिक ट्राफिक नथपी handshake र डेटा-मार्ग जाँचमा फर्कनुहोस्।

हरेक परीक्षणमा एउटा परिवर्तन राख्नुहोस् र प्रयोग गरिएको निष्क्रिय अवधि लेख्नुहोस्। त्यसो नगरे पछिको हरेक तुलना सर्छ र कुन परिवर्तन महत्त्वपूर्ण थियो भनेर कसैले भन्न सक्दैन। चार तथ्य एकैसाथ लेख्नुहोस्: दिशा, अवधि, निद्राको अवस्था र एपको व्यवहार।