काहीही काम करत नसताना VPN जोडलेले का दिसू शकते

तुमचा क्लायंट जोडलेले असे नोंदवतो, तर इंटरफेस वर आहे आणि ब्राउझरची वेळ संपते, आणि या तीन विधानांपैकी एकही खोटे नाही। जोडलेले हे तुम्ही मागितलेल्या पृष्ठाशी काहीही संबंध नसलेल्या स्तराचे वर्णन करते। कोणता स्तर नोंदवत आहे हे ठरवण्यासाठी एक नवीन विनंती आणि रहदारी हलली हे सिद्ध करणाऱ्या काउंटरवर एक नजर लागते। पुन्हा सुरू करणे तो पुरावा फेकून देते आणि तुम्ही निरीक्षण करू पाहत होतात त्या परिस्थिती पुन्हा तयार करते।

जोडलेले म्हटल्या जाणाऱ्या तीन वेगळ्या गोष्टी

सर्वात खाली, जोडलेले म्हणजे क्लायंट प्रक्रिया चालू आहे आणि सहकाऱ्याकडे सॉकेट धरून आहे। त्यावर, पत्त्यासह इंटरफेस अस्तित्वात आहे असे अर्थ असू शकतो, जो कायम उपकरण किंवा पुनर्प्राप्ती नित्यक्रम त्याच्या मागे कोणतेही जिवंत सत्र नसताना तयार करू शकतो। नियंत्रण स्तरावर, संलग्नतेवर बोलणी झाली असे अर्थ असू शकतो, जे तिच्या खालून एकही पॅकेट गेले का याबद्दल काहीही सांगत नाही। यापैकी प्रत्येक इतर सहन करत नाहीत अशा बिघाडांना तोंड देते, आणि क्लायंट सहसा आपण दावा करू शकणारे सर्वात बलवान दाखवतो।

म्हणून हिरवे चिन्ह आणि मृत बोगदा विरोधाभासी नसून सुसंगत आहेत; ते वेगवेगळ्या वस्तूंबद्दल नोंदवतात। हा बिघाड वारंवार क्लायंट बग म्हणून चुकीचे निदान होत राहण्याचे हेच संपूर्ण कारण आहे।

डीमनला स्पर्श करण्यापूर्वी तुम्हाला खरोखर आवश्यक असलेल्या गंतव्यस्थानावर एक निरुपद्रवी विनंती पाठवा, आणि काम करताना आवश्यक थेट रहदारीचा ब्लॉक जागेवर ठेवा। पुन्हा सुरू करणे घटनांचा क्रम पुसते आणि नंतर कारण लपवण्याइतक्या जवळ पुन्हा तयार करते, म्हणूनच तेच तिकीट आठवड्यानंतर आत काहीही नवीन नसताना परत येते। एक विनंती, काउंटरचे एक वाचन आणि बिघाड निर्माण करणारा ट्रिगर हा किमान पुरावा आहे।

कोणता काउंटर पॅकेट हलली हे सिद्ध करतो

IPsec मध्ये IKE संलग्नता आणि CHILD संलग्नता वेगळ्या वस्तू आहेत, आणि या प्रश्नाचे उत्तर देणारे काउंटर फक्त child कडे असतात। child ची यादी करा, पॅकेट दोन्ही दिशांनी वाढत आहेत का ते पहा, आणि अनुप्रयोग जे करू पाहतो त्याशी तुलना करा। शून्यावर स्थापित संलग्नता ही अनुप्रयोग अजूनही अपयशी होत असताना वाढणाऱ्या संलग्नतेपेक्षा वेगळी निष्पत्ती आहे; पहिली म्हणजे रहदारी निवडली जात नाही, दुसरी म्हणजे ती हलत आहे आणि बिघाड पुढे आहे। काउंटर दोन वेळा वाचा, काही सेकंदांच्या अंतराने, कारण एक नमुना कल दाखवू शकत नाही।

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

शून्य काउंटर निवडीकडे निर्देश करतात: मार्गक्रमण, धोरण, पॅकेट ज्या नामस्थानातून बाहेर पडले, किंवा ज्या इंटरफेसला क्लायंटने कधीही जोडले नाही। वाढणारे काउंटर बोगद्यापासून दूर निर्देश करतात, म्हणून दूरच्या टोकावरील अग्रेषण, नाव निराकरण, परतीचा मार्ग आणि गंतव्य सेवा याच क्रमाने पुढे जा। वेगळ्या child वस्तूशिवाय प्रोटोकॉल तोच पुरावा स्वतःच्या संज्ञांमध्ये उघड करतो, म्हणून IPsec ची शब्दसंग्रह उधार घेण्याऐवजी सहकाऱ्याची स्थिती आणि पॅकेट संख्या याबद्दल तो जे नोंदवतो ते वापरा। वाचनाचा आकार ते तयार करणाऱ्या साधनापेक्षा अधिक महत्त्वाचा आहे।

काउंटर हलल्यानंतर बिघाड कुठे बसतो

स्वतःच्या व्यवस्थापन पत्त्यावर उत्तर देणारा गेटवे गेटवे चालू आहे हे सिद्ध करतो, त्याच्या मागे काहीतरी तुमची विनंती पूर्ण करत आहे हे नव्हे, म्हणून मधल्या पेटीऐवजी दूरची बाजू तपासा। नाव निराकरण बिघाड सर्वात चांगल्या प्रकारे लपवते, कारण बोगद्यातून न पोहोचणारा रिझॉल्व्हर मृत जोडणीसारखाच वेळ संपवतो। दोन शोध त्या प्रसंगांना वेगळे करतात, आणि दोन्ही स्वस्त आहेत। आधी बोगदा जो रिझॉल्व्हर लादतो त्याला विचारा, नंतर त्याच नावाबद्दल सार्वजनिक रिझॉल्व्हरला विचारा।

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

सार्वजनिक रिझॉल्व्हरने सुटणारे पण बोगद्याच्या रिझॉल्व्हरने न सुटणारे नाव म्हणजे DNS मार्ग तुटलेला आहे, तर दोन्हीकडून सुटणारे आणि तरीही ब्राउझरमध्ये वेळ संपणारे नाव परतीचा मार्ग किंवा सेवा दर्शवते। पत्त्याने ping यशस्वी होऊनही अनुप्रयोग नकार देत असेल, तर नेटवर्कने विनंती पोहोचवली आणि सेवेने ती नाकारली, जी पूर्णपणे नंतरची पायरी आहे।

ट्रिगर नोंदवा, मग एक गोष्ट बदला

बिघाडापूर्वी काय घडले ते नोंदवा: काही काळ निष्क्रियता, नेटवर्क बदल, की नूतनीकरण, पुन्हा सुरू झालेला लॅपटॉप, किंवा पुनर्संचयित प्रणाली। हे वेगवेगळी यंत्रणा निर्माण करतात, आणि सहसा फक्त पुनर्संचयित प्रणाली स्वतःला दुरुस्त करते, जी तुम्हाला काहीही शिकवत नाही अशीच परिस्थिती आहे। पुन्हा सुरू करणे घटनांचा क्रम काढून टाकते आणि नंतर कारण लपवण्याइतक्या जवळच्या परिस्थिती पुन्हा तयार करते। ट्रिगर अजूनही पुनरुत्पादित होऊ शकतो तेव्हाच तो लिहून ठेवा।

नंतर एका आधारित दुरुस्ती करा आणि मूळ विनंती बिघाड निर्माण करणाऱ्या ट्रिगरसह पुन्हा करा। निष्क्रियता पुनरुत्पादनास सर्वात सोपा ट्रिगर आहे, म्हणून दुरुस्तीने लक्षण नव्हे तर यंत्रणा हाताळली हे सर्वात जलद पुष्टीकरण आहे।

तुम्हाला नोंदवायचे आहे तो पुरावा म्हणजे तुम्ही पाठवू पाहत होतात ती रहदारी तुम्ही पोहोचू पाहत होतात त्या सेवेपर्यंत पोहोचली। हिरवे होणारे चिन्ह, लोड होणारे कॅशे पृष्ठ आणि हलणारे काउंटर—हे सर्व हेतू असलेल्या गंतव्याकडे एका पूर्ण विनंतीपेक्षा कमी सिद्ध करतात। विनंती, काउंटरचे वाचन आणि ट्रिगर एकत्र ठेवा, जेणेकरून पुढील व्यक्ती दुरुस्ती आणि योगायोग वेगळे ओळखू शकेल।