Wi-Fi बदलने या Ethernet लगाने पर आपका VPN क्यों टूट जाता है
'नया SSID, एक्सेस पॉइंट के बीच रोमिंग और लगा हुआ केबल टनल को तीन अलग जगहों पर तोड़ते हैं। पहले स्रोत पता, फिर रूट, फिर प्रोटोकॉल जाँचें।'
दो चीज़ें एक ही खराबी के रूप में दर्ज होती हैं: लैपटॉप किसी दूसरे Wi-Fi नेटवर्क पर चला गया, या Wi-Fi चालू रहते ही केबल लग गया। क्लाइंट अब भी कहता है कि जुड़ा है, आइकन स्वस्थ दिखता है, और टनल कुछ भी नहीं ढोती। अंदर से केवल तीन स्थिति-टुकड़े हिल सकते हैं - लिंक, स्थानीय पता, डिफ़ॉल्ट रूट - और कौन हिला, यही तय करता है कि टनल खुद ठीक होगी या फिर से जुड़ना पड़ेगा। मैं इन्हें उसी क्रम में जाँचता हूँ, क्योंकि खाते की सेटिंग बदलने से आज तक इनमें से एक भी ठीक नहीं हुआ।
लिंक, पता और रूट अलग-अलग हिलते हैं
एक ही नेटवर्क के एक्सेस पॉइंट के बीच रोमिंग आम तौर पर L2 घटना है। रेडियो फिर से जुड़ता है, इंटरफ़ेस अपना पता और गेटवे बनाए रखता है, और टनल जिन चीज़ों पर निर्भर है उनमें से कुछ नहीं बदलता, इसीलिए बड़े दफ़्तर में चलना कभी-कभी ध्यान में नहीं आता। दूसरे SSID से जुड़ना वैसा नहीं है: पुराना इंटरफ़ेस नीचे जा सकता है, DHCP नया पता, नया गेटवे और नए रिज़ॉल्वर देता है, और टनल जो बाहरी प्रवाह इस्तेमाल कर रही थी वह अस्तित्व में नहीं रहता।
Ethernet तीसरा रूप जोड़ता है। Wi-Fi कभी नहीं गिरता, इसलिए कोई लिंक घटना जारी ही नहीं होती, फिर भी तार वाला इंटरफ़ेस अपने पते के साथ दिखाई देता है और अक्सर मीट्रिक पर डिफ़ॉल्ट रूट जीत जाता है। टनल ऐसे रास्ते पर चलती रहती है जो अब पसंद नहीं है, या क्लाइंट अपना सॉकेट उसी वायरलेस नेटवर्क से बाँधे रखता है जिस पर शुरू हुआ था। ब्राउज़र से दोनों एक जैसे दिखते हैं: केबल बैठते ही पेज अटक जाते हैं।
तो पहला सवाल यह नहीं है कि Wi-Fi बदला या नहीं। सवाल यह है कि जिस पते से आप बँधे हैं, या अंतिम बिंदु तक का रूट, टनल चालू रहते बदला या नहीं।
बाहरी सॉकेट ऐसे पते से बँधा है जो अभी गायब हुआ
हर टनल एक बाहरी प्रवाह है: एक स्थानीय पता और पोर्ट जो सर्वर के पते और पोर्ट से बात करते हैं। Linux पर वह पुराने स्रोत से बँधा UDP सॉकेट है; जब पता रखने वाला इंटरफ़ेस हट जाता है, तो भेजे गए पैकेट या तो EADDRNOTAVAIL के साथ विफल होते हैं या नए इंटरफ़ेस से ऐसे स्रोत के साथ निकलते हैं जिसे सर्वर ने कभी नहीं देखा।
दूसरी ओर अपनी बँधन रखती है। MOBIKE के बिना IKEv2 SA पता-युग्म से पहचाना जाता है, और एक OpenVPN सत्र उस पीयर पते से बँधा रहता है जो उसने सीखा, और NAT मैपिंग उसी निजी पते, पोर्ट और सार्वजनिक पते की होती है जिन्होंने उसे बनाया। किसी दूसरे NAT के पीछे जाइए और हर उत्तर ऐसी मैपिंग पर जाता है जो अब नहीं है। आपकी मशीन पर कुछ भी गलत कॉन्फ़िगर नहीं है; पाँच-टपल उस नेटवर्क की ओर इशारा करता है जो आपने छोड़ा।
सिद्धांत बनाने से पहले स्थिति पढ़ें:
ss -unpदिखाता है कि हर टनल सॉकेट वास्तव में कौन-सा स्थानीय पता और पोर्ट रखता है।ip route get 203.0.113.10वह स्रोत पता और डिवाइस छापता है जो कर्नेल अभी अंतिम बिंदु के लिए इस्तेमाल करेगा।wg show wg0 endpoints,swanctl --list-sasया क्लाइंट लॉग वह पीयर पता दिखाता है जिससे दूसरी ओर सोचती है कि बात कर रही है।
अगर सॉकेट का पता और रूट खोज मेल न खाएँ, तो आपने टूटन पा ली, और क्रेडेंशियल बदलने से उसे कुछ नहीं होगा।
नए स्रोत पते के साथ हर प्रोटोकॉल क्या करता है
क्लाइंट बदलाव को अलग-अलग मात्रा में सोखते हैं, और तालिका वही है जिसकी तुलना मैं क्लाइंट कॉन्फ़िग से करता हूँ, बजाय दोबारा जुड़ने के व्यवहार से अनुमान लगाने के।
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
WireGuard का रोमिंग नियम एक ही दिशा में काम करता है: क्लाइंट को पहले नए पते से भेजना होगा। पुराने इंटरफ़ेस से बँधा सॉकेट ऐसा कभी नहीं करता, इसीलिए टनल जीवित दिख सकती है जबकि उसका हैंडशेक टाइमर पुराना होता रहता है। प्रोटोकॉल वर्णन अंतिम बिंदु के अद्यतन की शर्त सटीक रूप से बताता है, और कॉन्फ़िग बदलने से पहले उसे पढ़ना उचित है।
MOBIKE पर बातचीत होती है, मान लिया नहीं जाता। अगर सर्वर इसे नहीं देता, तो क्लाइंट को फिर से स्थापित करना पड़ेगा, और यह ऐसा तथ्य है जिसे आप SA सूची या लॉग से पुष्ट करते हैं, किसी घूमते चक्र से अनुमान नहीं लगाते।
रास्ता रूट की प्राथमिकता तय करती है, Wi-Fi आइकन नहीं
दोनों इंटरफ़ेस ऊपर होने पर कर्नेल मीट्रिक और प्रीफ़िक्स लंबाई से चुनता है। ip route show default उम्मीदवारों की सूची देता है और ip route get 203.0.113.10 वास्तविक निर्णय सुलझाता है, स्रोत पते सहित। मीट्रिक 100 पर तार वाला डिफ़ॉल्ट और 600 पर वायरलेस का अर्थ है कि केबल बैठते ही अंतिम बिंदु हिल जाता है, जबकि पहले सॉकेट खोल चुका हर ऐप अपना पुराना स्रोत बनाए रखता है।
Windows भी स्वचालित इंटरफ़ेस मीट्रिक के साथ यही करता है, लिंक गति से पक्षपात लेकर। Get-NetRoute -DestinationPrefix 0.0.0.0/0 उम्मीदवारों को क्रमबद्ध करता है और Find-NetRoute -RemoteIPAddress 203.0.113.10 वह इंटरफ़ेस और स्रोत लौटाता है जो स्टैक चुनता। जो क्लाइंट अपना बाहरी सॉकेट एक इंटरफ़ेस से बाँधता है, वह मीट्रिक पलटने के बाद भी उसी का इस्तेमाल करता है; यह बँधन का निर्णय है, रूटिंग की खराबी नहीं।
Android बँटवारे को दृश्य बनाता है: ConnectivityManager उपलब्ध नेटवर्क और अलग डिफ़ॉल्ट बताता है, और जो VPN ऐप सॉकेट को Network ऑब्जेक्ट से बाँधता है वह दोबारा बाँधने तक वह बँधन रखता है। macOS पर, scutil --nwi प्राथमिक इंटरफ़ेस और वह क्रम छापता है जो सिस्टम इस्तेमाल करेगा।
DNS, MTU और IPv6 जुड़ाव के साथ हिलते हैं
नया जुड़ाव नए रिज़ॉल्वर लाता है। systemd-resolved के साथ DNS प्रति-लिंक है, resolvectl status दिखाता है कि कौन-सा लिंक किसी नाम का उत्तर देता है, और जो गेस्ट नेटवर्क अपना रिज़ॉल्वर देता है वह लिंक के फिर से प्राथमिक होने तक टनल द्वारा भेजे गए DNS को अप्रयुक्त छोड़ सकता है। कैप्टिव पोर्टल इसे और बिगाड़ता है: पहला HTTPS अनुरोध अंतिम बिंदु की बजाय पोर्टल उत्तर देता है, और क्लाइंट मृत सर्वर दर्ज कर लेता है।
रास्ते का MTU भी बदलता है। Ethernet और Wi-Fi आम तौर पर 1500 बाइट ढोते हैं, PPPoE 1492, और मोबाइल लिंक अक्सर कम। छोटा MTU विरासत में मिलने पर टनल बड़े पैकेट पर अटकती है जबकि छोटे अनुरोध सफल होते हैं, जिसे आधा टूटा कनेक्शन पढ़ा जाता है। ping -M do -s 1472 203.0.113.10 DF सेट करके 1500 बाइट का पैकेट भेजता है; खामोशी का अर्थ है कि रास्ता आपके अनुमान से छोटा है।
IPv6 दूसरा आधा है। नया प्रीफ़िक्स देने वाला नेटवर्क उस स्रोत को बदल देता है जो दोहरे स्टैक वाला क्लाइंट इस्तेमाल करेगा, और केवल v4 टनल नीति आने तक v6 ट्रैफ़िक को बाहर रखती है। ip -6 route show default और ip -6 addr show उत्तर देते हैं कि नए लिंक का v6 रास्ता है ही या नहीं।
वर्णन करने के बजाय संक्रमण को दोहराएँ
एक हानिरहित अनुरोध चुनें और बदलाव के दोनों ओर वही तीन आदेश चलाएँ: ip -br addr, ip route show default, ip route get 203.0.113.10। फिर देखें कि टनल अब भी पैकेट भेजती है या नहीं - tcpdump -ni any udp port 51820 WireGuard के लिए, बाकी सब के लिए मेल खाता पोर्ट। पुराने स्रोत से निकलते पैकेट का अर्थ बँधन की समस्या है। नए स्रोत से बिना उत्तर निकलते पैकेट का अर्थ दूसरी ओर या बीच का NAT है।
नोट करें कि पहली खराबी के साथ कौन-सी घटना मेल खाई: लिंक नीचे, पता बदलना, या डिफ़ॉल्ट रूट बदलना। ये अलग-अलग मालिकों की ओर इशारा करते हैं - ऐसा क्लाइंट जिसे दोबारा बाँधना है, ऐसा पता जिसे दोबारा लेना है, या ऐसा रूट जो कॉन्फ़िग फ़ाइल का है, स्थायी बायपास नियम का नहीं।
ठीक हुआ कहने से पहले पुष्टि करें कि सीधे ट्रैफ़िक का ब्लॉक अंतराल के दौरान भी टिका है और नाम नए जुड़ाव से हल होते हैं। अगर स्विच के बाद क्लाइंट पुराना अंतिम बिंदु रखता है, तो पहले रोमिंग या float सेटिंग ठीक करें। अगर वह सही रोम करता है और फिर भी उत्तर नहीं मिलता, तो सर्वर की पीयर पहचान और रास्ते के NAT को देखें, और दोनों नेटवर्क संदर्भ रिपोर्ट में रखें ताकि अगला व्यक्ति उनकी तुलना कर सके।