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