सार्वजनिक 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

पुराना बाहरी बंधन साफ़ करें

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

जाँच के दौरान ज़रूरी रोक लगी रहने दें। सुरंग ठीक होती है या नहीं, यह परखने के लिए नीति को पूरा खोल देना आपको कारण के बारे में कुछ नहीं सिखाता और तैनाती को जैसी पाई थी उससे बदतर छोड़ देता है।

नए अनुरोध के साथ दोबारा जाँचें

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

फिर निदान के दोनों आधे दर्ज करें: ऊपर के हिस्से में क्या बदला, और किस समर्थित रिकवरी चरण ने प्रवाह लौटाया। अगली बार तेज़ होगी, और नोट ही उसे तेज़ बनाता है।

अगर नया अनुरोध सफल हो और पुराना कभी फिर शुरू न हो, तो सुरंग ठीक हो गई थी और एप्लिकेशन को बस दोबारा जुड़ना है।