केही पनि काम नगर्दा 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 सफल भएर पनि एप्लिकेसनले अस्वीकार गरेमा सञ्जालले अनुरोध पुर्‍यायो र सेवाले त्यसलाई अस्वीकार गर्‍यो, जुन पूर्ण रूपमा पछिको चरण हो।

ट्रिगर लेख्नुहोस्, त्यसपछि एउटा कुरा बदल्नुहोस्

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

त्यसपछि एउटा आधारित सुधार गर्नुहोस् र मूल अनुरोधलाई खराबी निम्त्याउने ट्रिगरसँगै दोहोर्‍याउनुहोस्। निष्क्रियता पुनरुत्पादन गर्न सबैभन्दा सजिलो ट्रिगर हो, त्यसैले सुधारले लक्षण नभई संयन्त्रलाई सम्बोधन गरेको सबैभन्दा छिटो पुष्टि हो।

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