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 और डेटा-पथ जाँच पर लौटें।

हर जाँच में एक बदलाव रखें और इस्तेमाल की गई निष्क्रिय अवधि लिखें। इसके बिना हर बाद की तुलना सरक जाती है और कोई नहीं बता सकता कि कौन-सा बदलाव मायने रखता था। चार तथ्य साथ लिखें: दिशा, अवधि, नींद की स्थिति और ऐप का व्यवहार।