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 सफल हो और अनुप्रयोग अब भी इनकार करे, तो नेटवर्क ने प्रार्थना पहुँचाई और सेवा ने उसे अस्वीकार किया, जो पूरी तरह बाद का चरण है।

ट्रिगर दर्ज करें, फिर एक चीज़ बदलें

दर्ज करें कि विफलता से पहले क्या हुआ: निष्क्रियता की अवधि, नेटवर्क परिवर्तन, कुंजी नवीनीकरण, फिर से चालू हुआ लैपटॉप, या पुनर्स्थापित सिस्टम। ये अलग-अलग तंत्र उत्पन्न करते हैं, और आमतौर पर केवल पुनर्स्थापित सिस्टम ही स्वयं को ठीक करता है, जो ठीक वही स्थिति है जो आपको कुछ नहीं सिखाती। पुनः आरंभ घटनाओं का क्रम हटा देता है और फिर कारण छिपाने के लिए पर्याप्त निकट स्थितियाँ फिर बनाता है। ट्रिगर तब लिखें जब वह अब भी पुनरुत्पादन योग्य है।

फिर एक समर्थित सुधार करें और मूल प्रार्थना को विफलता पैदा करने वाले ट्रिगर के साथ दोहराएँ। निष्क्रियता पुनरुत्पादन के लिए सबसे आसान ट्रिगर है, इसलिए यह सबसे तेज़ पुष्टि है कि सुधार ने लक्षण नहीं, तंत्र को संबोधित किया।

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