NetGuard ന്റെ SOCKS മോഡ് TCP ഉൾക്കൊള്ളുന്നു, എല്ലാ പ്രോട്ടോക്കോളും അല്ല
NetGuard Android ന്റെ VPN ഇന്റർഫേസ് വഴി ട്രാഫിക് ഫിൽട്ടർ ചെയ്യുന്നു, പിന്തുണയുള്ള കണക്ഷനുകൾ SOCKS ലേക്ക് നൽകാം. UDP, DNS, പ്രൊഫൈലുകൾക്കിടയിലുള്ള എത്തിച്ചേരൽ എന്നിവയ്ക്ക് പ്രത്യേക ഓഡിറ്റ് വേണം.
NetGuard ട്രാഫിക് ഫിൽട്ടർ ചെയ്യാൻ Android ന്റെ VPN ഇന്റർഫേസ് ഉപയോഗിക്കുന്നു, പിന്തുണയുള്ള കണക്ഷനുകൾ SOCKS എൻഡ്പോയിന്റിലേക്ക് നൽകാനും കഴിയും. ഈ രണ്ട് വസ്തുതകളും പലപ്പോഴും “ഫോൺ ഒരു VPN-ൽ ആണ്” എന്ന് വായിക്കപ്പെടുന്നു, അത് ഈ സംവിധാനം പിന്തുണയ്ക്കാത്ത ഒരു നിഗമനമാണ്. ഫിൽട്ടർ പാക്കറ്റുകൾ കാണുന്നു; പ്രോക്സി തനിക്ക് യഥാർത്ഥത്തിൽ നൽകിയ കണക്ഷനുകൾ മാത്രം കാണുന്നു. ഈ രണ്ട് പ്രസ്താവനകൾക്കിടയിലാണ് കവറേജിന്റെ മുഴുവൻ ചോദ്യം.
ഉറവിട പ്രോജക്റ്റിന്റെ FAQ ഒറ്റ-സേവന പരിമിതിയും SOCKS ഓപ്ഷനും രേഖപ്പെടുത്തുന്നു. ഓപ്ഷന്റെ നിലനിൽപ്പ് അനുവദിച്ച ഓരോ പാക്കറ്റും അത് ഉപയോഗിക്കുന്നു എന്നതിന് തെളിവല്ല, ഈ വിടവിൽ നിന്നാണ് കവറേജ് ചോദ്യങ്ങൾ ഉയരുന്നത്.
ഒരു ആപ്പിനുള്ളിൽ രണ്ട് ഫോർവേർഡിംഗ് പാതകൾ
നടപ്പാക്കലിന്റെ TCP ഭാഗത്ത് SOCKS കണക്ഷൻ കൈകാര്യം ചെയ്യൽ ഉണ്ട്, അതിനാൽ അനുവദിച്ച TCP കണക്ഷൻ പ്രോക്സിയുമായി ചർച്ച ചെയ്ത് അതിലൂടെ കൊണ്ടുപോകാം. UDP ഭാഗത്തിന് പ്രത്യേക സോക്കറ്റ് പാതയുണ്ട്, അതിന്റെ അയയ്ക്കലും സ്വീകരണവും ഈ TCP ചർച്ചയെ ആശ്രയിക്കുന്നില്ല. അതിനാൽ ഫിൽട്ടർ അനുവദിക്കുന്ന ഡാറ്റാഗ്രാം ഒരിക്കലും പ്രോക്സിയിലൂടെ കടന്നുപോകാതെ സാധാരണ നെറ്റ്വർക്കിൽ എത്താം. ഇതിൽ ആപ്പിന്റെ തകരാറില്ല; രണ്ട് പാതകൾ നടപ്പാക്കുന്നത് ഇത്രമാത്രം.
ഈ വ്യത്യാസത്തിന് ആളുകൾ ഇരുവശത്തേക്കും തെറ്റായി പറയുന്ന ഒരു അനന്തരഫലമുണ്ട്. ഓരോ UDP പാക്കറ്റിനെയും ചോർച്ച എന്ന് വിളിക്കുന്നത് തടയൽ നിയമങ്ങളെ അവഗണിക്കുന്നു, കാരണം നിരസിച്ച ഡാറ്റാഗ്രാം ഒരിക്കലും പുറത്തുപോകുന്നില്ല. മുഴുവൻ ക്രമീകരണത്തെയും VPN എന്ന് വിളിക്കുന്നത് അനുവദിച്ച നേരിട്ടുള്ള പാതയെ അവഗണിക്കുന്നു, കാരണം കുറച്ച് ട്രാഫിക് യഥാർത്ഥത്തിൽ പ്രോക്സിയില്ലാതെ പുറത്തുപോകുന്നു. നിങ്ങളുടെ കൈവശമുള്ളത് ഭാഗിക പ്രോക്സിയുള്ള ഫിൽട്ടർ ചെയ്ത ഉപകരണമാണ്, സത്യസന്ധമായ വിവരണം ലേബലല്ല, ഒരു മാട്രിക്സ് ആണ്.
UDP പ്രഖ്യാപിക്കുന്നത് അത് നടപ്പാക്കുന്നതല്ല
UDP പിന്തുണ അവകാശപ്പെടുന്ന SOCKS സെർവർ നിങ്ങളുടെ ഫോണിലെ ആപ്പിലേക്ക് അനുബന്ധ ക്ലയന്റ്-വശ കൈകാര്യം ചേർക്കുന്നില്ല. പ്രോട്ടോക്കോളിന്റെ സൈദ്ധാന്തിക സവിശേഷതകളും ഇൻസ്റ്റാൾ ചെയ്ത ബിൽഡിന്റെ സ്വഭാവവും വ്യത്യസ്ത വിഷയങ്ങളാണ്, നിങ്ങളുടെ ട്രാഫിക് വിവരിക്കുന്നത് രണ്ടാമത്തേത് മാത്രം.
നിങ്ങൾ യഥാർത്ഥത്തിൽ പ്രവർത്തിപ്പിക്കുന്ന പതിപ്പും ക്രമീകരണവും പരിശോധിച്ച്, പിന്നീട് ഒരു നിരുപദ്രവ ഡാറ്റാഗ്രാം പ്രവാഹം പരീക്ഷിച്ച് അത് പ്രോക്സിയിൽ പ്രത്യക്ഷപ്പെടുന്നുണ്ടോ എന്ന് നിരീക്ഷിക്കുക. ബാക്കിയെല്ലാം സവിശേഷതാ പട്ടികയിൽ നിന്നുള്ള അനുമാനമാണ്, സവിശേഷതാ പട്ടികകൾ കോഡ് പാതകളല്ല, ഉദ്ദേശ്യങ്ങളാണ് വിവരിക്കുന്നത്.
DNS മൂന്നാം പാതയാണ്, വിശദാംശമല്ല
പേര് വിശകലനം മാട്രിക്സിലേക്ക് സ്വന്തം ശാഖ ചേർക്കുന്നു. പ്രാദേശിക DNS ഫോർവേർഡർ, സാധാരണ UDP അന്വേഷണം, പ്രോക്സി തന്നെ പരിഹരിക്കുന്ന ലക്ഷ്യ ഹോസ്റ്റ്നാമം, ബ്രൗസറിലെ എൻക്രിപ്റ്റ് ചെയ്ത റിസോൾവർ എന്നിവ നാല് വ്യത്യസ്ത ക്രമീകരണങ്ങളാണ്. അന്വേഷണം ആര് കാണുന്നു, ഏത് നെറ്റ്വർക്ക് പാത അത് വഹിക്കുന്നു എന്നിവയിൽ അവ വ്യത്യസ്തമാണ്, അവ കലർത്തുന്നത് മറ്റുള്ളവയെക്കുറിച്ച് ഒന്നും തെളിയിക്കാത്ത പരീക്ഷണം നൽകുന്നു.
ഏതാണ് വേണ്ടതെന്ന് ബോധപൂർവം തീരുമാനിക്കുക. പേരുകൾ ടണലിലൂടെ പരിഹരിക്കണം എന്നതാണ് ആവശ്യമെങ്കിൽ, ബ്രൗസർ ക്രമീകരണം മാത്രം അത് നൽകില്ല, ഹോസ്റ്റ്നാമങ്ങൾ സ്വയം പരിഹരിക്കുന്ന പ്രോക്സി താൻ യഥാർത്ഥത്തിൽ കൈകാര്യം ചെയ്യുന്ന കണക്ഷനുകൾക്ക് മാത്രം ഉത്തരം മാറ്റുന്നു.
പ്രോക്സി ഗതാഗതം സ്വയമേവ സ്വകാര്യമല്ല
സാധാരണ SOCKS ഫോണിൽ നിന്ന് പ്രോക്സിയിലേക്കുള്ള എൻക്രിപ്റ്റ് ചെയ്ത കണ്ണിയല്ല. എൻഡ്പോയിന്റിൽ മറ്റൊരു സംരക്ഷിത പാതയിലൂടെ എത്തുന്നുവെങ്കിൽ, ആ പാതയും അതിന്റെ പരാജയ നയവും പേരിടുക, കാരണം തുറന്ന നെറ്റ്വർക്കിലേക്കുള്ള പിൻവാങ്ങൽ മുന്നറിയിപ്പില്ലാതെ സ്വകാര്യ ക്രമീകരണത്തെ പൊതുവായതാക്കുന്നു. പ്രോക്സിയുടെ സ്വന്തം പ്രാമാണീകരണവും പ്രധാനമാണ്: പങ്കിട്ട ഉപകരണത്തിലെ തുറന്ന ശ്രോതാവ് ആരും കണക്ക് പറയാത്ത ഒരു സേവനമാണ്.
പ്രൊഫൈലുകൾക്കിടയിലുള്ള ക്രമീകരണങ്ങൾക്കും അതേ പരിശോധന വേണം. ജോലി പ്രൊഫൈലിന്റെ VPN അതിന്റെ പാത ഉപയോഗിക്കുന്ന ട്രാഫിക്കിനെ മാത്രം സംരക്ഷിക്കുന്നു, വ്യക്തിഗത പ്രൊഫൈലിലെ ഫയർവാളും ജോലി ടണലും ഒരുമിച്ചുള്ളത് ഫയർവാളിന്റെ തുടർന്നുള്ള കണക്ഷൻ ആ ടണലിൽ എത്തുന്നു എന്ന് തെളിയിക്കുന്നില്ല. രണ്ട് പ്രൊഫൈലുകൾ സഹകരിക്കുന്നു എന്ന് അനുമാനിക്കുന്നതിനുപകരം എത്തിച്ചേരലും പ്രാമാണീകരണവും പരിശോധിക്കുക.
പേജ് ലോഡ് കൊണ്ടല്ല, മാട്രിക്സ് കൊണ്ട് കവറേജ് ഓഡിറ്റ് ചെയ്യുക
അധികാരപ്പെടുത്തിയ വിലയിരുത്തലിനായി, നിങ്ങൾക്ക് പ്രധാനമായ ഓരോ വിഭാഗത്തെയും പ്രതിനിധീകരിക്കുന്ന നിരുപദ്രവ ഉദാഹരണങ്ങൾ തിരഞ്ഞെടുക്കുക: ആവശ്യമായ TCP, അനുവദിച്ച UDP, രണ്ട് വിലാസ കുടുംബങ്ങളിലെ DNS. ഓരോന്നിനും അത് പ്രോക്സി ചെയ്യപ്പെട്ടോ, തടയപ്പെട്ടോ, നേരിട്ട് അയച്ചതോ എന്ന് രേഖപ്പെടുത്തുക. ആ ഒരു പട്ടികയാണ് ഫലം, ലോഡ് ചെയ്ത പേജിന്റെ സ്ക്രീൻഷോട്ടിനേക്കാൾ ഇത് വളരെ ഉപയോഗപ്രദമാണ്.
തിരഞ്ഞെടുത്ത എല്ലാ ആപ്ലിക്കേഷൻ ട്രാഫിക്കും ഒരു വിദൂര ടണലിലൂടെ കടന്നുപോകണം എന്നതാണ് ആവശ്യമെങ്കിൽ, സംയോജിത ഫിൽട്ടറിംഗും ടണലിംഗും വ്യക്തമായി പിന്തുണയ്ക്കുന്ന ഒരു നടപ്പാക്കൽ തിരഞ്ഞെടുക്കുക. TCP മാത്രമുള്ള പ്രോക്സി ഘടന ഇടുങ്ങിയ ജോലികൾക്ക് ഉപയോഗപ്രദമായി തുടരുന്നു, മറ്റ് ട്രാഫിക് മറക്കാതെ ഉദ്ദേശപൂർവം കൈകാര്യം ചെയ്താൽ.