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-ஐயும் பாருங்கள், அடுத்த நபர் ஒப்பிட முடியும்படி இரு நெட்வொர்க் சூழல்களையும் அறிக்கையில் வைத்திருங்கள்.