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 प्रोफ़ाइल बदलने से ऐसी अपलिंक ठीक नहीं होगी जो बार-बार फिर से बातचीत करती रहती है। एक ही मिनट में प्रविष्टियों की एक जोड़ी उस घटना के लिए प्रश्न तय कर देती है और अगली के लिए आधार-रेखा देती है।