VPN गाड़ी चलाते समय फिर जुड़ता है: रेडियो बदलाव या IP बदलाव?
टावरों के बीच हैंडओवर IP पथ को अक्षुण्ण छोड़ सकता है। जो क्लाइंट टनल को खिसकाते हैं उनकी तुलना उनसे करें जो उसे फिर से बनाते हैं, और नेटवर्क की घटना पढ़ें, सफ़र नहीं।
जब आप कस्बे के किनारे से गुज़रते हैं तो कॉल कट जाती है, और VPN का आइकन उसी पल गायब हो जाता है। इसे “टावर बदलने ने टनल को मार डाला” के रूप में दर्ज करना लुभावना है। दो अलग बातें हुईं, और उनमें से केवल एक टावरों से जुड़ी है। एक रेडियो हैंडओवर आपका IP पता, डिफ़ॉल्ट रूट और सत्र पूरी तरह अक्षुण्ण छोड़ सकता है, जबकि असली पता बदलाव हर ऐसी टनल तोड़ देगा जो उसके साथ नहीं खिसक सकती। क्लाइंट उस दूसरी स्थिति को कैसे संभालते हैं, इसकी तुलना करना ही उपयोगी अभ्यास है, क्योंकि यह बताता है कि आप रचा हुआ व्यवहार देख रहे हैं या खराबी।
टावर बदलना ज़रूरी नहीं कि पता बदलना हो
मोबाइल नेटवर्क हैंडओवर के दौरान पैकेट सत्र जीवित रखते हैं जब तक ऑपरेटर का मोबिलिटी एंकर एक ही रहे। रेडियो लिंक बदलता है, टनल उसे नोटिस नहीं करती, और किसी भी लॉग में दोबारा जुड़ना नहीं दिखना चाहिए। शहर के भीतर आवाजाही के लिए यही सामान्य स्थिति है।
पता वह बदलता है जो एंकरों के बीच स्थानांतरण, Wi-Fi से सेलुलर पर जाना, या लंबे अंतराल के बाद ऑपरेटर की ओर टनल का पुनःस्थापन है। वे घटनाएँ आपके पैकेटों के द्वारा ले जाए जाने वाले स्रोत पते को बदल देती हैं, और VPN साथी एक खिसके हुए साथी को देखता है।
व्यावहारिक नतीजा यह है कि आवाजाही प्रमाण नहीं है। चालीस किलोमीटर चला उपकरण पूरे रास्ते एक ही पता रख सकता है, और स्थिर खड़ा उपकरण दो बार पता बदल सकता है क्योंकि नेटवर्क ने ऐसा तय किया। घटना को दर्ज करना ही उन दोनों में फ़र्क़ करने का एकमात्र तरीका है।
दो रचनाएँ: टनल को खिसकाएँ या फिर से बनाएँ
क्लाइंट इस बात में अलग हैं कि बाहरी स्रोत बदलने की उन्हें कितनी परवाह है। कुछ टनल को उस पते से बाँधते हैं जिस पर वह बनी थी और पूर्ण पुनःस्थापन माँगते हैं। अन्य हर पैकेट को स्वतंत्र रूप से सत्यापित करते हैं और केवल यह अद्यतन करते हैं कि जवाब कहाँ भेजने हैं।
| Mechanism | Behaviour after the source changes | What the user notices |
|---|---|---|
| WireGuard | Endpoint updated on the next authenticated packet | Usually nothing; the tunnel continues |
| IKEv2 with MOBIKE | Security association moves to the new address | Short pause, no re-authentication |
| OpenVPN over UDP with float | Peer address may change without a restart | Might survive, depending on timing |
| Client bound to one address | Session dies and is rebuilt | A visible reconnect and a new authentication |
ऊपरी पंक्ति बहुत सी उलझी रिपोर्टों की व्याख्या करती है। WireGuard के पास तोड़ने के लिए कोई सत्र नहीं है: हर पैकेट साथी का सूचकांक ले जाता है और सत्यापित होता है, इसलिए नए पते से आने वाला वैध पैकेट परिभाषा से उसी साथी का है, और दर्ज किया गया अंतिम बिंदु उसका पीछा करता है। सफ़र भर लगातार “जुड़ा हुआ” दिखाने वाला क्लाइंट सच कह रहा है।
निचली पंक्ति भी खराबी नहीं है। सत्र को फिर से बनाना मौजूदा पते के विरुद्ध सत्यापन दोबारा चलाता है, और पुराना पता अब किसी और का हो सकता है—तब आप ठीक यही चाहते हैं।
आवाजाही नहीं, घटना देखें
Android में कनेक्टिविटी उपतंत्र नेटवर्क परिवर्तनों को घटना के रूप में रिपोर्ट करता है, और वही आपको क्लाइंट के व्यवहार से जोड़ना चाहिए। डंप लंबा है, पर प्रासंगिक हिस्से डिफ़ॉल्ट नेटवर्क और उसका पता हैं:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40सर्वर की ओर रोमिंग स्थिति के लिए सीधा मापन मौजूद है। WireGuard हर साथी के लिए अंतिम सत्यापित अंतिम बिंदु संग्रहीत करता है, इसलिए पता बदलाव दोबारा जुड़ने के बजाय बदले हुए मान के रूप में दिखता है:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesसफ़र से पहले और बाद में अंतिम बिंदु की तुलना करें। यदि पता और पोर्ट अपरिवर्तित हैं, तो टनल को कुछ करने की ज़रूरत नहीं थी और दोबारा जुड़ना कहीं और से, आमतौर पर एप्लिकेशन से आया। यदि अंतिम बिंदु बदला पर हैंडशेक की समय-मुद्रा सामान्य कुंजी नवीनीकरण अंतराल के निकट रही, तो टनल फिर से शुरू नहीं हुई, खिसक गई।
फिर से शुरू होना अलग दिखता है: हैंडशेक की समय-मुद्रा दोबारा जुड़ने के क्षण पर रीसेट हो जाती है, और क्लाइंट शांत निरंतरता के बजाय आरंभ क्रम लॉग करता है।
कब दोबारा जुड़ना ही सही व्यवहार है
हर दोबारा जुड़ने को खराबी मानने से ऐसी कॉन्फ़िगरेशन बनती हैं जो मृत सत्रों को जीवित रखती हैं। जिस साथी का पता बदला क्योंकि नेटवर्क ने उसे फिर से आवंटित किया, उसे पुराने मैपिंग के लिए ट्रैफ़िक लेना जारी नहीं रखना चाहिए, और चुपचाप चलता रहने वाला क्लाइंट आइकन हरा रहते हुए काले छेद में भेज सकता है।
उपयोगकर्ता के दृष्टिकोण से दोनों विफलताओं की तुलना करें। दोबारा जुड़ने में कुछ सेकंड और एक नया सत्यापन लगता है। पुरानी टनल में ऐसा एप्लिकेशन लगता है जो बिना त्रुटि के अटक जाता है, जिसे समझाना कहीं अधिक कठिन है और “इंटरनेट खराब हो गया” के रूप में रिपोर्ट होने की संभावना कहीं अधिक है।
इसके नीचे नीति का सवाल भी छिपा है। एक रास्ता खोने और दूसरा स्थापित करने के बीच के अंतराल में कुछ क्लाइंट सीधे ट्रैफ़िक भेजने पर लौट जाते हैं। उसे रोकना स्वचालित पुनर्प्राप्ति से अलग नियंत्रण है, और क्लाइंट एक में अच्छा और दूसरे में खराब हो सकता है। किसी को भी ट्यून करने से पहले तय करें कि आपको कौन चाहिए।
देखा गया क्रम लिखें
उपयोगी रिपोर्ट घटना के स्रोत का नाम लेती है: नए पते के साथ डिफ़ॉल्ट नेटवर्क का बदलाव, Wi-Fi से सेलुलर पर जाना, या बिना किसी पता बदलाव के हैंडओवर। फिर वह बताती है कि क्लाइंट ने क्या किया, स्मृति से नहीं बल्कि सर्वर की ओर की समय-मुद्रा के साथ।
यदि टनल खिसकी है, तो कहें और नया अंतिम बिंदु परिवार नोट करें। यदि फिर से स्थापित हुई है, तो नोट करें कि सत्यापन पहले प्रयास में सफल हुआ और अंतराल कितना रहा। ये तीन तथ्य स्वस्थ मोबाइल रचना को नेटवर्कों के बीच भटकते क्लाइंट से अलग करते हैं।
और “टावर बदलाव” वाक्यांश से बचें, जब तक कि उपकरण का लॉग वास्तव में इसे सिद्ध न करे। Android का कनेक्टिविटी दस्तावेज़ उन कॉलबैक का वर्णन करता है जो उपलब्धता को डिफ़ॉल्ट नेटवर्क बदलाव से अलग करते हैं, और आपकी रिपोर्ट को ठीक वही भेद चाहिए। बाकी सब गाड़ी चलाने की कहानी है।