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 चे कनेक्टिव्हिटी दस्तऐवज उपलब्धतेला डीफॉल्ट नेटवर्क बदलापासून वेगळे करणाऱ्या कॉलबॅकचे वर्णन करते, आणि तुमच्या अहवालाला नेमका तोच फरक हवा आहे। बाकी सर्व गाडी चालवण्याची गोष्ट आहे।