राउटर रीबूट के बाद अटका VPN: तीन बातें जो बदलीं

राउटर बूट होकर तैयार हो जाता है, लैपटॉप उसी SSID से फिर जुड़ जाता है, और VPN बिना कुछ हिले जुड़ा हुआ पड़ा रहता है। सहेजी गई प्रोफ़ाइल अक्षत है। उसके नीचे जो समाप्त हुआ वह रास्ता था, और क्लाइंट अब भी पुरानी प्रोफ़ाइल के लिए बनाई गई स्थिति थामे हुए है।

तीन शर्तें समाधान तय करती हैं। इन्हें क्रम से जाँचें, क्योंकि पहली शर्त ही अटकाव का कारण बता दे तो बाद की शर्तें व्यर्थ श्रम हैं।

शर्त एक: स्थानीय पता बदल गया है

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

क्लाइंट जो पता इस्तेमाल कर रहा है उसकी तुलना इंटरफ़ेस के अभी के पते से करें। डिफ़ॉल्ट मार्ग जो ऐसे गेटवे की ओर इशारा करता है जो खुद बदल गया है, वही समस्या दूसरे नाम से है।

ip -4 addr show
ip route show default
ip route get 203.0.113.10

शर्त दो: अनूदित मैपिंग चली गई है

घर के राउटर बाहर जाते प्रवाहों का अनुवाद करते हैं, और वे मैपिंग स्मृति में रहती हैं। रीबूट उनमें से हर एक को मिटा देता है। यह नए कनेक्शन के लिए निर्दोष और ऐसी टनल के लिए घातक है जो मानती है कि उसका मौजूदा प्रवाह अभी भी वैध है। फिर सामने वाला पक्ष कुछ नहीं देखता, इसलिए क्लाइंट को कभी ऐसी त्रुटि नहीं मिलती जिस पर कार्रवाई की जा सके।

यहीं keepalive रहित टनल ज़ोर से विफल होने के बजाय चुपचाप अटक जाती है। WireGuard के प्रलेखित सीमाएँ इसी प्रकार की विफलता का वर्णन करती हैं। गलत एंडपॉइंट स्थिति निदान के बजाय गिराए गए पैकेट पैदा करती है।

25 सेकंड का लगातार keepalive सामान्य उपाय है, क्योंकि यह निष्क्रिय समय-सीमा पूरी होने से पहले मैपिंग को ताज़ा करता है। यह पहले ही जा चुकी मैपिंग की मरम्मत नहीं करता। keepalive को समाधान मानने के बजाय पुनः कनेक्शन तर्क से जोड़ें।

शर्त तीन: सार्वजनिक पता बदल गया है

अगर राउटर का अपना बाहरी पता बदल गया हो, तो दूसरी ओर स्रोत पते से फ़िल्टर करने वाला हर तत्व अब दूसरा सहभागी देखता है। टनल ऊपर आ सकती है और सर्वर फिर भी ट्रैफ़िक छोड़ सकता है; यह टूटे क्लाइंट जैसा दिखता है और वास्तव में दूसरे सिरे की नीति है।

रीबूट से पहले और बाद में बाहरी पता दर्ज करें। जब दोनों अलग हों, प्रश्न क्लाइंट से हटकर अनुमति-सूची रखने वाले के पास चला जाता है, और लैपटॉप पर क्रेडेंशियल रीसेट करने से मदद नहीं मिल सकती।

सही क्रम में बहाल करें

पहले आवश्यक captive-portal साइन-इन पूरा करें, फिर प्रोसेस को मारने के बजाय क्लाइंट को उसकी समर्थित प्रक्रिया से फिर जुड़ने दें। देखें कि पहचान और डेटा ट्रैफ़िक दोनों लौट रहे हैं या नहीं, क्योंकि ये एक ही कनेक्शन के दो अलग चरण हैं।

कैश किया गया पेज कुछ सिद्ध नहीं करता, और न ही अपने आप फिर जुड़ा चैट ऐप। जिस एंडपॉइंट की वास्तव में परवाह है उसे नए अनुरोध से जाँचें। बाधा के दौरान सीधे-ट्रैफ़िक की नीति लागू रखें, क्योंकि पुनः कनेक्शन का प्रयास अवरोध नहीं है।

जब यह हर रीबूट के बाद दोहराता है, तो रिकॉर्ड पुनः प्रयास से अधिक मायने रखता है। पहले और बाद में स्थानीय पता, गेटवे, बाहरी पता और क्लाइंट स्थिति दर्ज करें, फिर दोनों स्तंभों की तुलना करें। यह अस्पष्ट शिकायत को जीवनचक्र की ऐसी बग में बदल देता है जिसे कोई ठीक कर सके, और मैपिंग टाइमआउट के कारण प्रमाणपत्रों को तीसरी बार बदलने से रोक देता है।