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 हेर्नुहोस्, र अर्को व्यक्तिले तुलना गर्न सकून् भनेर दुवै सञ्जाल सन्दर्भ प्रतिवेदनमा राख्नुहोस्।