ഹോട്ട്‌സ്‌പോട്ട് ക്ലയന്റുകൾക്ക് സ്പ്ലിറ്റ് ടണലിംഗ് ആപ്പ് അനുസരിച്ചുള്ള ഒഴിവാക്കലല്ല
ഒരു ആപ്പിനെ VPN-ൽ നിന്ന് ഒഴിവാക്കുന്നത് ഫോണിനെ മാത്രമാണ് മാറ്റുന്നത്. ടെതർ ചെയ്ത ലാപ്‌ടോപ്പിന് സ്വന്തം ഫോർവേഡിംഗ് നിയമം വേണം, അത് ഉറവിടം, ലക്ഷ്യം, NAT എന്നിവയിൽ പൊരുത്തപ്പെടുത്തുന്നു.
ഒരേപോലെ തോന്നുന്ന രണ്ട് ആവശ്യങ്ങൾ ഒന്നല്ല: «ഈ ആപ്പിനെ VPN-ൽ നിന്ന് ഒഴിവാക്കുക», «എന്റെ ഹോട്ട്‌സ്‌പോട്ടിലെ ലാപ്‌ടോപ്പിനായി ഈ ഒരു ലക്ഷ്യം VPN-ന് പുറത്തേക്ക് അയയ്ക്കുക». ആദ്യത്തേത് ഫോണിലെ സോക്കറ്റ് ഒരു നെറ്റ്‌വർക്ക് എങ്ങനെ തിരഞ്ഞെടുക്കുന്നു എന്നത് മാറ്റുന്നു. രണ്ടാമത്തേത് ഫോൺ ഇതിനകം സ്വീകരിച്ചതിന് ശേഷം മറ്റൊരു ഉപകരണത്തിൽ നിന്ന് വന്ന പാക്കറ്റിനുള്ള ഫോർവേഡിംഗ് തീരുമാനം മാറ്റണം. രണ്ടും കൂട്ടിക്കുഴയ്ക്കുന്നതാണ് ഹോട്ട്‌സ്‌പോട്ട് ക്ലയന്റിന് എപ്പോഴും ഫോണിന്റെ സ്വന്തം ബ്രൗസറിന് മാത്രം ബാധകമായിരുന്ന ഒരു ഒഴിവാക്കൽ അവശേഷിപ്പിക്കുന്നത്.
രണ്ട് ചോദ്യങ്ങളുടെ ഉടമകൾ രണ്ട് വ്യത്യസ്ത സബ്‌സിസ്റ്റങ്ങളാണ്
Android ആപ്പ് നെറ്റ്‌വർക്കിംഗും ടെതറിംഗും വേർതിരിച്ച് വയ്ക്കുന്നു. ആപ്പുകളുടെ സോക്കറ്റുകൾ കണക്റ്റിവിറ്റി സ്റ്റാക്ക് ഒരു നെറ്റ്‌വർക്കിന് അനുവദിക്കുന്നു, ഒരു VPN ആപ്പ് അതിന്റെ സ്വന്തം സോക്കറ്റുകളിൽ ഏതൊക്കെ ടണലിൽ പ്രവേശിക്കുന്നു എന്ന് തീരുമാനിക്കുന്നു. ടെതർ ചെയ്ത ക്ലയന്റിൽ നിന്ന് ഫോർവേഡ് ചെയ്യുന്ന പാക്കറ്റുകൾ ടെതറിംഗ് സബ്‌സിസ്റ്റം കൈകാര്യം ചെയ്യുന്നു, അത് netd-നോട് റൂട്ടുകൾ, നയ നിയമങ്ങൾ, താഴത്തെ ഇന്റർഫേസിലെ വിവർത്തനം എന്നിവ ആവശ്യപ്പെടുന്നു.
ആപ്പ് അനുസരിച്ചുള്ള ഒഴിവാക്കൽ ഒരു ആപ്പ് സോക്കറ്റ് തുറക്കുമ്പോൾ വിലയിരുത്തുന്നു. ഫോർവേഡ് ചെയ്ത പാക്കറ്റ് ആ പരിശോധനയിൽ ഒരിക്കലും എത്തുന്നില്ല, കാരണം അത് ഈ ഉപകരണത്തിലെ ആപ്പ് സോക്കറ്റിൽ നിന്ന് ഉത്ഭവിച്ചതല്ല. രണ്ട് ക്രമീകരണങ്ങൾക്ക് പരസ്പരം പകരം വയ്ക്കാൻ കഴിയാത്തതിന്റെ മുഴുവൻ കാരണം ഇതാണ്, ഇത് രണ്ടിലും ഒരു ബഗ് അല്ല.
ആപ്പ് അനുസരിച്ചുള്ള ഒഴിവാക്കൽ യഥാർത്ഥത്തിൽ എന്താണ് മാറ്റുന്നത്
VpnService ബിൽഡർക്ക് addDisallowedApplication ഉപയോഗിച്ച് ടണലിന് പുറത്ത് നിൽക്കുന്ന പാക്കേജുകൾ പേരിടാം, അല്ലെങ്കിൽ addAllowedApplication ഉപയോഗിച്ച് അകത്ത് അനുവദിച്ച ഏക പാക്കേജുകൾ പേരിടാം. ആ ആപ്പുകൾ പിന്നീട് അടിസ്ഥാന നെറ്റ്‌വർക്കിൽ സോക്കറ്റുകൾ തുറക്കുന്നു, VPN ബാക്കിയുള്ള എല്ലാറ്റിനും സ്ഥിര റൂട്ട് കൈവശം വയ്ക്കുന്നു.
പരിധി കൃത്യമാണ്: പാക്കേജിന്റെ സ്വന്തം സോക്കറ്റുകൾ, ഈ ഉപകരണത്തിൽ, ടണൽ ഉയർന്നിരിക്കുന്നിടത്തോളം. ഫോർവേഡ് ചെയ്ത ട്രാഫിക്കിനെക്കുറിച്ച് ഇത് ഒന്നും പറയുന്നില്ല, രണ്ടാമത്തെ ഉപകരണത്തെക്കുറിച്ചും ഒന്നുമില്ല, സിസ്റ്റം ടെതറിംഗിന് വേണ്ടി അയയ്ക്കുന്ന പാക്കറ്റുകളെക്കുറിച്ചും ഒന്നുമില്ല.
ഇത് ലക്ഷ്യ നിയന്ത്രണവുമല്ല. ഒരു ബ്രൗസർ ഒഴിവാക്കുന്നത് ആ ബ്രൗസർ എത്തുന്ന ഓരോ വിലാസവും ഒഴിവാക്കുന്നു, ടണലിനുള്ളിൽ നിലനിർത്താൻ ആഗ്രഹിച്ചതും ഉൾപ്പെടെ. ആവശ്യം ആപ്പിന് പകരം ലക്ഷ്യം എന്ന് പേരിടുമ്പോൾ, ആപ്പ് തിരഞ്ഞെടുക്കൽ ഘടനാപരമായി തന്നെ തെറ്റായ ഉപകരണമാണ്.
ഫോണിന് ടെതർ ചെയ്ത പാക്കറ്റ് എങ്ങനെ കാണപ്പെടുന്നു
ക്ലയന്റിന്റെ പാക്കറ്റ് ഹോട്ട്‌സ്‌പോട്ട് ഇന്റർഫേസിൽ ഫോൺ അനുവദിച്ച സ്വകാര്യ ഉറവിട വിലാസത്തോടെ, പറയട്ടെ 192.168.43.20, പൊതു ലക്ഷ്യത്തോടെ എത്തുന്നു. അത് ഫോർവേഡ് ചെയ്യാൻ ഫോണിന് മുകളിലേക്കുള്ള കണ്ണിയിലേക്ക് ഒരു റൂട്ടും വിവർത്തന നിയമവും വേണം, അല്ലെങ്കിൽ മറുപടികൾക്ക് തിരികെയുള്ള വഴി കണ്ടെത്താനാകില്ല, കാരണം ക്ലയന്റിന്റെ സ്വകാര്യ വിലാസം സെല്ലുലാർ നെറ്റ്‌വർക്കിൽ അർത്ഥശൂന്യമാണ്.
Android ഇത് ഒരു റൂട്ടിംഗ് പട്ടിക തിരഞ്ഞെടുക്കുന്ന നയ നിയമങ്ങളിലൂടെ പ്രകടിപ്പിക്കുന്നു, നെറ്റ്‌വർക്കുകളും VPN-കളും മാറുമ്പോൾ netd ബന്ധപ്പെട്ട പട്ടികകളും നിയമങ്ങളും വീണ്ടും നിർമ്മിക്കുന്നു. ഒരു ഫോറം പോസ്റ്റിൽ നിന്നോ അതേ മോഡലിന്റെ പഴയ റിലീസിൽ നിന്നോ പകർത്തിയ പട്ടിക നമ്പർ, നിയമ മുൻഗണന അല്ലെങ്കിൽ ഇന്റർഫേസ് പേര് സ്ഥിരമായ ഉടമസ്ഥത സ്ഥാപിക്കുന്നില്ല. ഈ പുനർനിർമ്മാണമാണ് കൈകൊണ്ട് എഴുതിയ ഒരു നിയമം ഒരു മണിക്കൂർ പ്രവർത്തിച്ച് അടുത്ത പുനർബന്ധനത്തിന് ശേഷം നിലയ്ക്കാനുള്ള കാരണവും.
ഹോട്ട്‌സ്‌പോട്ട് ഒഴിവാക്കലിന് യഥാർത്ഥത്തിൽ വേണ്ട നയം
ഒരു നിയമം തൊടുന്നതിന് മുമ്പ് തീരുമാനം ഉറവിടം, ലക്ഷ്യം, ഉദ്ദേശിച്ച വഴി എന്നിവയായി എഴുതുക. അംഗീകരിച്ച ഒരു ലക്ഷ്യത്തിനുള്ള ഏറ്റവും ചെറിയ രൂപം ഇങ്ങനെയാണ്:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
രണ്ട് ദിശകളും പൂർണ്ണമായിരിക്കണം. നേരിട്ടുള്ള ശാഖയ്ക്ക് ഇപ്പോൾ നിലവിലുള്ള സെല്ലുലാർ മുകളിലേക്കുള്ള കണ്ണി വഴിയുള്ള ഉപയോഗയോഗ്യമായ ഒരു റൂട്ട് വേണം; VPN ശാഖയ്ക്ക് ടണൽ റൂട്ടും ഫോർവേഡ് ചെയ്യാനുള്ള അനുമതിയും വേണം. ഏതൊരു ഉറവിട വിവർത്തനവും നിങ്ങൾ തിരഞ്ഞെടുത്ത പുറത്തേക്കുള്ള വഴിയുമായി പൊരുത്തപ്പെടണം, കാരണം ടണൽ ഇന്റർഫേസിൽ പ്രയോഗിക്കുന്ന NAT ടണലിന്റെ വിലാസമാണ് കാണിക്കുന്നത്, സെല്ലുലാറിന്റേതല്ല, അപ്പോൾ മടങ്ങിവരുന്ന വഴി പോകുന്ന വഴിയുമായി പൊരുത്തപ്പെടുന്നില്ല.
മറുപടികൾ ട്രാക്ക് ചെയ്ത അവസ്ഥയിലൂടെയോ വ്യക്തമായ റൂട്ടിലൂടെയോ അതേ താഴത്തെ ക്ലയന്റിൽ എത്തണം, പുറത്തേക്ക് പോകുന്ന പാക്കറ്റ് കൗണ്ടർ അതിൽ ഒന്നും തെളിയിക്കുന്നില്ല. VPN-ന്റെ സ്വന്തം പുറം ഗതാഗതവും ഒഴിവാക്കലിന്റെ പരിധിക്ക് പുറത്ത് നിർത്തുക, അല്ലെങ്കിൽ ടണലിന്റെ വാഹക പാക്കറ്റുകൾ ഒരു ക്ലയന്റിന്റെ വെബ് അഭ്യർത്ഥനയ്ക്കായി എഴുതിയ നയം അവകാശമായി ലഭിക്കും.
പിടിച്ചെടുത്ത ഒരു വിലാസം ലക്ഷ്യമല്ല
ഒരു ബ്രൗസറിൽ നിന്ന് വായിച്ച ഒരു IPv4 വിലാസം ഒരു നിമിഷ ചിത്രമാണ്. വലിയ സേവനങ്ങൾ anycast-ൽ നിന്നോ കറങ്ങുന്ന എഡ്ജ് വിലാസങ്ങളുടെ ഒരു കൂട്ടത്തിൽ നിന്നോ മറുപടി നൽകുന്നു, പലതും ഇരട്ട-സ്റ്റാക്ക് ആണ്, ഒരു ലോഗിൻ പ്രവാഹം പേജ് ഒരിക്കലും കാണിക്കാത്ത ഒത്തുതീർപ്പും ടെലിമെട്രിയും ഹോസ്റ്റുകളെ സ്പർശിച്ചേക്കാം. യാദൃശ്ചികമായി കണ്ട വിലാസത്തിന് ചുറ്റും നിർമ്മിച്ച ഒഴിവാക്കൽ സേവനം ലോഡ് വീണ്ടും സംതുലനം ചെയ്യുന്ന അടുത്ത തവണ തകരുന്നു.
സേവന ഉടമയുടെ രേഖപ്പെടുത്തിയ വിലാസങ്ങളോ അദ്ദേഹം പ്രസിദ്ധീകരിക്കുന്ന ഒരു ശ്രേണിയോ ഉപയോഗിക്കുക, രണ്ട് വിലാസ കുടുംബങ്ങളും കണക്കിലെടുക്കുക. ആവശ്യം സ്ഥിരമായ ഒരു കൂട്ടമായി പ്രകടിപ്പിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, അത് ഒരു ഫോണിലെ റൂട്ടിംഗ് തന്ത്രമല്ല, സേവനത്തിനുള്ള ഒരു നയ ചോദ്യമാണ്.
താഴത്തെ വശത്ത് നിന്ന് പരിശോധിക്കുക
മൂന്ന് പരിശോധനകൾ, ഈ ക്രമത്തിൽ: ലാപ്‌ടോപ്പിൽ നിന്ന് തിരഞ്ഞെടുത്ത സേവനം, VPN-നുള്ളിൽ നിൽക്കേണ്ട ഒരു സാധാരണ ലക്ഷ്യം, ബാധിക്കപ്പെടരുതാത്ത ഒരു ഫോൺ ആപ്പ്. തുടർന്ന് പുനർബന്ധനത്തിന് ശേഷവും മുകളിലേക്കുള്ള കണ്ണി മാറിയതിന് ശേഷവും ആവർത്തിക്കുക, കാരണം അപ്പോഴാണ് നയ പട്ടികകൾ വീണ്ടും നിർമ്മിക്കുന്നത്.
ഫോണിന്റെ പങ്കിടൽ നിർവ്വഹണത്തിന് പുനർബന്ധനത്തിലുടനീളം ആ കരാർ നിലനിർത്താൻ കഴിയുന്നില്ലെങ്കിൽ, ഹാൻഡ്‌സെറ്റിൽ root നിയമങ്ങൾ കൂട്ടിവയ്ക്കുന്നതിന് പകരം തിരഞ്ഞെടുത്ത നയം പിന്തുണയുള്ള ഒരു താഴത്തെ റൂട്ടറിലേക്ക് മാറ്റുക. ഒരു റൂട്ടറിന് സ്ഥിരമായ ഉടമയോടെ ഉറവിട-ലക്ഷ്യ പൊരുത്തം പ്രകടിപ്പിക്കാനാകും, ടെതറിംഗ് മൊഡ്യൂളിന്റെ ഡോക്യുമെന്റേഷൻ ഫോൺ യഥാർത്ഥത്തിൽ എന്താണ് ചെയ്യുന്നത് എന്നതിനുള്ള ശരിയായ റഫറൻസാണ്.