सार्वजनिक IP परिवर्तन भयो र VPN ले ट्राफिक पार गर्न छोड्यो

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

चार जाँच क्रममा गर्नुहोस् र पहिलो असफल हुनेमा रोकिनुहोस्।

वास्तवमा कुन ठेगाना परिवर्तन भयो

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

बाहिरी स्रोत परिवर्तन भयो, भित्री सुरुङ ठेगाना परिवर्तन भयो, वा दुवै भयो भनी निश्चित रूपमा सोध्नुहोस्। केवल पहिलोले अब नभएको मार्गमा पठाइरहने साथीलाई व्याख्या गर्छ।

स्थानान्तरण प्रोटोकलले नै सम्हालोस्

साथी सरेको थाहा पाउने तरिकामा प्रोटोकलहरू फरक छन्, र यो भिन्नता तपाईंले हस्तक्षेप गर्नुपर्छ कि भन्ने प्रश्नमा महत्त्वपूर्ण छ। WireGuard ले त्यो साथीको कुञ्जीले प्रमाणित हुने प्याकेट प्राप्त गर्दा त्यसको अन्त्य बिन्दु अद्यावधिक गर्छ, त्यसैले कुनै कन्फिगरेसनबिना ठेगाना परिवर्तन स्वीकार गर्न सकिन्छ। IKEv2 सँग त्यही उद्देश्यका लागि MOBIKE छ, जहाँ दुवै छेउले यसलाई समर्थन गर्छन्। पुराना ढाँचाहरू सुरुङ पुनः निर्माण गरेर सुधार हुन्छन्।

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

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

पुरानो बाहिरी बन्धन सफा गर्नुहोस्

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

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

नयाँ अनुरोधसँग फेरि परीक्षण गर्नुहोस्

परिवर्तनअघि स्थापित अनुप्रयोग सत्र त्यसलाई पार गर्दैन, किनकि यो जोडिएको चार-टुपल अब छैन। पुनःप्राप्तिपछि नयाँ अनुरोध सिर्जना गर्नुहोस् र त्यो पूरा हुन्छ भनी पुष्टि गर्नुहोस्; पुरानो डाउनलोड शून्यमा अडिएको देखेर सुरुङ अझै बिग्रिएको छ भनी निष्कर्ष निकाल्नुहोस्। यही एउटा भिन्नताले यस्ता प्रतिवेदनको ठूलो हिस्सा समाधान गर्छ।

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

यदि नयाँ अनुरोध सफल भयो र पुरानो कहिल्यै पुनः सुरु भएन भने, सुरुङ मर्मत भइसक्यो र अनुप्रयोगले फेरि जोडिनु मात्र पर्छ।