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 आणि डेटा-मार्ग तपासणीकडे परत जा।

प्रत्येक चाचणीत एक बदल ठेवा आणि वापरलेला निष्क्रिय कालावधी लिहा। तसे न केल्यास पुढील प्रत्येक तुलना सरकते आणि कोणता बदल महत्त्वाचा होता हे कोणीही सांगू शकत नाही। चार गोष्टी एकत्र नोंदवा: दिशा, कालावधी, झोपेची स्थिती आणि ॲपचे वर्तन।