सुरुङ माथि आउँछ, लगले पूरा भएको ह्यान्डशेक देखाउँछ, र एक सेकेन्डपछि त्यही सत्र मर्छ र लुपमा फेरि जोडिन्छ। यो ढाँचाको निश्चित कारण छ: सर्भरसम्मको बाटो अब सुरुङभित्र देखाउँछ, त्यसैले सुरुङ बोक्ने प्याकेट सुरुङबाटै पठाइन्छ। प्रमाणीकरणमा केही बदलिएको छैन, त्यसैले प्रमाणहरू फेरि हाल्दा कुनै फरक पर्दैन। रुट परिवर्तन हुनुअघि र पछिको बाहिरी बाटो तुलना गर्नुहोस्, पुनरावृत्ति देखिन थाल्छ।

पहिले बाहिरी बाटो जाँच्नुहोस्

खेलमा दुई प्याकेट छन्, एउटा होइन। भित्री प्याकेट अनुप्रयोगको हो र यसलाई इन्क्रिप्ट गरिएको हुनुपर्छ, जबकि बाहिरी प्याकेट सर्भरमा ठेगाना गरिएको छ र यसले सुरुङमा निर्भर नहुने बाटोबाट त्यहाँ पुग्नुपर्छ।

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

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

सत्र किन एकछिन टिक्छ

नयाँ रुट जडान हुनुअघि नै ह्यान्डशेक पूरा हुन्छ, त्यसैले पहिलो केही सेकेन्ड स्वस्थ देखिन्छ। क्लाइन्टले डिफल्ट रुट थप्ने बित्तिकै अर्को बाहिरी प्याकेट त्यसैको पछि त्यो इन्टरफेसमा पस्छ जहाँबाट त्यो प्याकेट जानुपर्छ। सर्भरले केही देख्दैन, क्लाइन्ट फेरि पठाउँछ, र प्रयास या त समय सकिएर रोकिन्छ या सत्र मारेर फेरि सुरु हुन्छ।

यही क्रमले सुरुङ ल्यापटपमा किन चल्छ तर राउटरमा किन असफल हुन्छ, र असफलता जडानको बेला नभई ट्राफिक सुरु हुँदा किन सुरु हुन्छ भन्ने बताउँछ। यसले लुप पनि बताउँछ: हरेक पुनःसुरुवातले सत्र फेरि स्थापित गर्छ, त्योभन्दा अघि बाटोले त्यसलाई असम्भव बनाउँछ।

इन्डप्वाइन्टको अपवादको मालिक को हो पत्ता लगाउनुहोस्

समर्थित क्लाइन्टहरू आफ्नै अपवाद मिलाउँछन्: मूल गेटवेबाट सर्भरसम्म होस्ट रुट, वा बाहिरी सकेटलाई सुरुङबाहिर राख्ने मार्क। प्रश्न यो हो कि अरू कसैले त्यो हटायो वा माथि चढ्यो।

रुट-आधारित IPsec मा कुन प्याकेट सुरुङमा पस्छन् भन्ने निर्णय गर्ने नीति-चयनकर्ता जाँच्नुहोस् र पियरको ठेगाना तिनबाट बाहिर राखिएको पुष्टि गर्नुहोस्। WireGuard मा इन्टरफेसको फायरवाल मार्क र त्यसका नीति नियमले ढुवानी प्याकेट सुरुङबाहिर राख्छन्, त्यसैले हातले थपिएको डिफल्ट रुटले त्यो व्यवस्था तोड्न सक्छ। दोस्रो VPN प्रोफाइल वा डिफल्ट रुट फेरि लेख्ने व्यवस्थापन स्क्रिप्ट सामान्यतया दोषी हुन्छ। एक-एक गरी थपिएका फराकिला बाइपास नियम नै सामान्य नतिजा हुन्, र तिनले रुटिङ बगलाई कसैले धान्न नसक्ने तालिकामा बदल्छन्।

नेटवर्क परिवर्तनपछि फेरि जाँच्नुहोस्

Wi-Fi गेटवेबाट जाने होस्ट रुट मेसिन अर्को नेटवर्कमा नपुगुन्जेल ठीक हुन्छ। त्यसपछि त्यही लक्षण कुनै कन्फिगरेसन परिवर्तन बिना फर्केर आउँछ।

इन्डप्वाइन्टको ठेगाना, जडान अघि र पछिको बाटो, र हरेकले प्रयोग गरेको इन्टरफेस लेख्नुहोस्। यी तीन तथ्यले सामान्यतया क्लाइन्टको गल्तीलाई अतिक्रमणबाट छुट्याउँछन्, र ती जम्मा गर्ने व्यक्ति गएपछि पनि रहन्छन्।

नयाँ नेटवर्कमा फेरि जोडिनुहोस् र पढाइ दोहोर्याउनुहोस्। अपवाद फेरि छैन भने, सुधार त्यो भएको प्रोफाइलमै पर्छ, अवरोधका बेला टाइप गरिएको एक-पटकको आदेशमा होइन।

सम्बन्धित लेखहरू