WAN IP परिवर्तन भयो र टनेल खस्यो: जाँच क्रममा

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

लग पढ्नुअघि घटनाको नाम राख्नुहोस्

पहुँच तहमा वास्तवमै के भयो जाँच्नुहोस्। ISP लीज नवीकरण एउटा घटना हो। पुन: जोडिएको PPPoE सत्र अर्को हो। रिबुट भएको फाइबर मोडेम, वा एउटा अपलिङ्कबाट अर्कोमा WAN फेलओभर, बाहिरी ठेगाना वा त्यसको मार्ग तेस्रो तरिकाले बदल्छ। यी एउटै घटना होइनन् र एउटै अवशेष छोड्दैनन्।

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

रोमिङ र पुन: जडान फरक प्रोटोकल हुन्

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

OpenVPN पूर्वनिर्धारित रूपमा फरक व्यवहार गर्छ। UDP सत्र अन्त्य भई फेरि जोडिन सक्छ, र वैकल्पिक float व्यवहारले प्रमाणित पियरलाई कन्फिगरेसनले अनुमति दिएको ठाउँमा नयाँ ठेगानाबाट जारी राख्न दिन्छ। TCP आधारित टनेल बढी कडा छन्, किनभने जडान आफैं ठेगाना जोडीसँग बाँधिएको छ। त्यही भिन्नताले पुन:प्राप्ति अदृश्य देखिने वा हरेक पटक लगमा आफ्नो घोषणा गर्ने निर्धारण गर्छ।

दुवै व्यवहारले भित्रका अनुप्रयोगबारे केही भन्दैनन्। पुन:प्राप्त टनेलले पियरले पहिले नै मृत मानेको TCP सत्र पुन:स्थापित गर्दैन।

टनेलको स्वामित्वमा नभएको अवस्था

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

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

जाँचहरूलाई बाहिरबाट भित्रतर्फ क्रममा राख्नुहोस्

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

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

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

त्यसपछि राउटरबाट होइन, LAN ग्राहकबाट परीक्षण गर्नुहोस्। राउटरले नै पठाएको पिङ फर्वार्ड गरिएको ट्राफिकभन्दा फरक मार्ग प्रयोग गर्छ, त्यसैले सफल राउटर पिङले टनेल अस्तित्वमा रहेको प्रमाणित गर्छ, र ग्राहकको पहुँचबारे केही भन्दैन।

अपेक्षित व्यवहार तय गर्नुहोस् र लेख्नुहोस्

अधिकांश परिनियोजनका लागि पुन: जडान सही व्यवहार हो, त्यसैले लक्ष्य यसलाई रोक्नु होइन। बरु अन्तरालमा ट्राफिकलाई के हुनुपर्छ तय गर्नुहोस्: रोक्ने, होल्ड गर्ने, वा अर्को मार्गमा फेलओभर गर्ने। त्यो निर्णय फायरवाल र रुटिङ नीतिको हो, VPN प्रोफाइलको होइन।

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