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-ഉം നോക്കുക, അടുത്തയാൾക്ക് താരതമ്യം ചെയ്യാനായി രണ്ട് നെറ്റ്‌വർക്ക് സന്ദർഭങ്ങളും റിപ്പോർട്ടിൽ സൂക്ഷിക്കുക.