VPN ഓണായിരിക്കുമ്പോൾ Android ഫയർവാൾ നിയമം എവിടെ വേണം
ഒരു VpnService മാത്രമേ സജീവമാകാനാകൂ, അതിനാൽ ഫയർവാൾ ആപ്പും VPN ആപ്പും ഒന്നിന് മീതെ ഒന്നായി കൂടുന്നില്ല. ഒരു ജോലി അഭ്യർത്ഥന പിന്തുടർന്ന് ഓരോ നിയമവും അതിന്റെ ട്രാഫിക് യഥാർത്ഥത്തിൽ കടന്നുപോകുന്നിടത്ത് വയ്ക്കുക.
നിങ്ങൾക്ക് ഒരു വാക്യത്തിന്റെ നയമുണ്ട്: ഈ ആപ്പിന് ജോലി സേവനത്തിൽ എത്താം, മറ്റൊന്നിലുമില്ല. അടുത്ത ചോദ്യം ഉൽപ്പന്ന തിരഞ്ഞെടുപ്പായി തോന്നാം, പക്ഷേ അത് സ്ഥലത്തെക്കുറിച്ചുള്ള ചോദ്യമാണ്, കാരണം സാധ്യമായ ഓരോ നിർവ്വഹണ പോയിന്റും ഫോണിന്റെ ട്രാഫിക്കിന്റെ വ്യത്യസ്ത ഭാഗം കാണുന്നു. ഗേറ്റ്വേ ടണലിൽ പ്രവേശിക്കുന്നത് മാത്രം കാണുന്നു. ഫോൺ വശത്തെ ഫിൽട്ടർ കാണാൻ അനുവാദമുള്ളത് മാത്രം കാണുന്നു. ഒരു അഭ്യർത്ഥന രണ്ടിലൂടെയും കടത്തിവിട്ടാൽ ഉത്തരം വ്യക്തമാകും.
ഉൽപ്പന്നത്തിൽ നിന്നല്ല, വാക്യത്തിൽ നിന്ന് തുടങ്ങുക
എന്തെങ്കിലും തിരഞ്ഞെടുക്കുന്നതിന് മുൻപ് ആവശ്യകത വികസിപ്പിക്കുക. അത് പാക്കേജും അത് പ്രവർത്തിക്കുന്ന പ്രൊഫൈലും എന്നാണർത്ഥം, കാരണം ജോലി പ്രൊഫൈലിലെ ആപ്പ് വ്യക്തിഗത പ്രൊഫൈലിലെ അതേ ആപ്പിൽ നിന്ന് വ്യത്യസ്ത ഉപയോക്താവാണ്. അത് ലക്ഷ്യസ്ഥാനം എന്നാണർത്ഥം: ഹോസ്റ്റ്, പോർട്ട്, പ്രോട്ടോക്കോൾ, സേവനത്തിന്റെ പേരല്ല. ആ പേര് പരിഹരിക്കുന്ന DNS പാതയും അത് അർത്ഥമാക്കുന്നു, ടണൽ ലഭ്യമല്ലാത്തപ്പോൾ എന്ത് സംഭവിക്കണം എന്നതും അതിൽ ഉൾപ്പെടുന്നു.
എഴുതിയാൽ ഉദാഹരണത്തിന്റെ നയം നാല് വരികളാണ്: ജോലി ആപ്പിന് ജോലി സേവനത്തിൽ എത്താം; മറ്റൊന്നിലും എത്താൻ പാടില്ല; മറ്റ് ആപ്പുകൾ മാറ്റമില്ലാതെ തുടരും; ടണൽ ഇല്ലെങ്കിൽ ജോലി ആപ്പ് നേരിട്ടുള്ള പാതയിലേക്ക് വീഴുന്നതിന് പകരം നിരസിക്കപ്പെടും. ഓരോ വരിക്കും ഒരു ഉടമയുണ്ട്, എല്ലാവരും ഒരേ ഉടമയല്ല.
ഘട്ടം 1: ഫോണിന് തന്നെ എന്ത് നിർവ്വഹിക്കാം
റൂട്ട് ഇല്ലാത്ത Android ഫയർവാൾ ഒരു VpnService ആണ്, അത് ട്രാഫിക് പ്രാദേശികമായി പിടിക്കുന്നു, പിന്നിൽ വിദൂര ടണൽ ഇല്ലെങ്കിലും. Android ഓരോ ഉപയോക്തൃ പ്രൊഫൈലിനും ഒരു സജീവ VPN സേവനം മാത്രം അനുവദിക്കുന്നു, അതിനാൽ രണ്ടാമത്തെ ഫയർവാൾ ആപ്പ് ആദ്യത്തേതിന് പിന്നിൽ ചേരുന്നില്ല. അത് അതിനെ മാറ്റിസ്ഥാപിക്കുന്നു, ആദ്യ ആപ്പ് ഫിൽട്ടർ ചെയ്തിരുന്ന ഇന്റർഫേസ് അപ്രത്യക്ഷമാകുന്നു.
അതുകൊണ്ടാണ് VPN ക്ലയന്റിന് അരികിൽ ഫയർവാൾ ഇൻസ്റ്റാൾ ചെയ്യുമ്പോൾ ആളുകൾ പ്രതീക്ഷിക്കുന്ന സംയോജനം അപൂർവ്വമായി ലഭിക്കുന്നത്. ഫയർവാൾ ആരംഭിച്ച് VPN വിച്ഛേദിക്കപ്പെട്ടാൽ ഒന്നും സംയോജിപ്പിച്ചിട്ടില്ല; രണ്ടും സ്ഥലം മാറി. ഇന്റർഫേസ് മാറ്റിസ്ഥാപിക്കുന്നത് സഹകരണമല്ല, ലക്ഷണം മറ്റേ ആപ്പ് തുറക്കുമ്പോഴെല്ലാം ടണൽ വീണ്ടും വീഴുന്നതാണ്.
പിന്തുണയുള്ള ക്രമീകരണങ്ങളുണ്ട്: നിങ്ങൾ ഇപ്പോൾ ഉപയോഗിക്കുന്ന VPN ക്ലയന്റിൽ ഉൾച്ചേർത്ത ഫിൽട്ടറിംഗ്, ഉപകരണ നയ നിയന്ത്രകൻ അല്ലെങ്കിൽ ജോലി പ്രൊഫൈൽ വഴി കൈകാര്യം ചെയ്യുന്ന പ്ലാറ്റ്ഫോം നിയന്ത്രണങ്ങൾ, അല്ലെങ്കിൽ നിർമ്മാതാവ് രേഖപ്പെടുത്തുന്ന ആർക്കിടെക്ചർ. ബാക്കിയെല്ലാം ഓരോ ആപ്പ് അപ്ഡേറ്റിനും ശേഷം വീണ്ടും പരിശോധിക്കേണ്ട പരീക്ഷണമാണ്.
ഘട്ടം 2: ഗേറ്റ്വേക്ക് എന്ത് നിർവ്വഹിക്കാം
വിദൂര അറ്റത്ത് ട്രാഫിക് ഡീക്രിപ്റ്റ് ചെയ്തതിന് ശേഷം, ഗേറ്റ്വേക്ക് കൈമാറുന്ന പാക്കറ്റുകൾ അംഗീകൃത വിലാസങ്ങളിലേക്കും സേവനങ്ങളിലേക്കും പ്രാമാണീകരിച്ച VPN ഐഡന്റിറ്റികളിലേക്കും പരിമിതപ്പെടുത്താം. അതിൽ നിന്ന് പുറത്തുപോകുന്ന എല്ലാറ്റിനും അത് യഥാർത്ഥ നിർവ്വഹണമാണ്, സ്വകാര്യ സബ്നെറ്റുകളിലേക്കുള്ള പ്രവേശനം പരിമിതപ്പെടുത്താൻ ശരിയായ സ്ഥലവുമാണ്.
അത് ലഭിക്കാത്തത് ഓരോ സാധാരണ IP പാക്കറ്റിലും ഘടിപ്പിച്ചിരിക്കുന്ന ഫോണിന്റെ ആപ്പ് ഐഡന്റിറ്റിയാണ്. ഒരു ടണൽ വിലാസം പങ്കിടുന്ന പല ആപ്പുകൾ ഗേറ്റ്വേക്ക് ഒരു വിഷയമാണ്, ഡിസൈൻ അവർക്ക് വേറിട്ട വിലാസങ്ങളോ വേറിട്ട പ്രാമാണീകൃത ഐഡന്റിറ്റികളോ നൽകുന്നില്ലെങ്കിൽ. അതിനാൽ ഗേറ്റ്വേയിലെ ഉപയോക്തൃതല നിയമം ഫോണിലെ ആപ്പ്തല നിയമമല്ല, മാനേജ്മെന്റ് കൺസോൾ എന്ത് വിളിച്ചാലും.
ഘട്ടം 3: ഒരിക്കലും എത്താത്തത് പട്ടികപ്പെടുത്തുക
VPN-ൽ നിന്ന് ഒഴിവാക്കിയ ആപ്പ് അടുത്തുള്ള ഉപകരണവുമായി ബന്ധപ്പെട്ടാൽ ഗേറ്റ്വേയിൽ ഒരിക്കലും എത്തുന്നില്ല, അതിനാൽ പുറത്തേക്കുള്ള ഫയർവാൾ ഒരിക്കലും ലഭിക്കാത്ത പാക്കറ്റ് നിരസിക്കാനാവില്ല. തടസ്സസമയത്ത് അവിചാരിതമായ നേരിട്ടുള്ള പാതയ്ക്കും പ്രാദേശിക ആക്സസ് നെറ്റ്വർക്കിലെ ഇൻബൗണ്ട് എക്സ്പോഷറിനും ഇത് തന്നെ ബാധകമാണ്. ഇവ നിർവചനപ്രകാരം പ്രാദേശിക അതിരുകളാണ്.
വിപരീതവും ശരിയാണ്: കണക്ഷൻ അനുവദിക്കുന്ന പ്രാദേശിക നിയമം ഗേറ്റ്വേയുടെ സ്വകാര്യ നെറ്റ്വർക്ക് ACL വഴി പ്രവേശനം നൽകുന്നില്ല. ഒരു അഭ്യർത്ഥന രണ്ട് അതിരുകൾക്കും വിധേയമായേക്കാം, ഒന്ന് നിറവേറ്റുന്നത് മറ്റൊന്നിനെപ്പറ്റി ഒന്നും പറയുന്നില്ല.
ഘട്ടം 4: ഓരോ നിയമവും ഒരു പാതയ്ക്ക് നൽകുക
എന്തെങ്കിലും കോൺഫിഗർ ചെയ്യുന്നതിന് മുൻപ് തീരുമാനം പട്ടികയിൽ വയ്ക്കുക, കാരണം ശൂന്യമായ കളങ്ങളാണ് ഡിസൈനുകൾ പരാജയപ്പെടുന്ന സ്ഥലം.
| പാത | ആർക്ക് നിർവ്വഹിക്കാം | അന്ധ ബിന്ദു |
|---|---|---|
| ജോലി ആപ്പിൽ നിന്ന് ജോലി സേവനത്തിലേക്ക്, ടണൽ തുറന്നിരിക്കുന്നു | വിലാസത്തിലും സേവനത്തിലും ഗേറ്റ്വേ ACL, കൂടെ മറ്റ് പാതകളിൽ പ്രാദേശിക തടയൽ | ഏത് ആപ്പാണ് പാക്കറ്റ് അയച്ചതെന്ന് ഗേറ്റ്വേക്ക് കാണാനാവില്ല |
| ജോലി ആപ്പിൽ നിന്ന് മറ്റ് ലക്ഷ്യങ്ങളിലേക്ക്, ടണൽ തുറന്നിരിക്കുന്നു | ആപ്പ് അറിയുന്ന പ്രാദേശിക ഫിൽട്ടർ, അല്ലെങ്കിൽ ആ ലക്ഷ്യങ്ങൾ അവിടെ വിലാസപ്പെടുത്തിയിട്ടുണ്ടെങ്കിൽ ഗേറ്റ്വേ | പ്രാദേശിക ഫിൽട്ടർ സജീവ VpnService ആയിരിക്കണം |
| ടണൽ ഇല്ലാത്ത ജോലി ആപ്പ് | പ്രാദേശിക നിരസിക്കൽ, ആപ്പിന് നേരിട്ടുള്ള പാത എടുക്കാൻ കഴിയാതിരിക്കാൻ | ടണൽ പോയാലും ഫിൽട്ടർ നിലനിൽക്കണം |
| അടുത്തുള്ള LAN ഉപകരണം | പ്രാദേശിക നയം മാത്രം | ഗേറ്റ്വേ അത് ഒരിക്കലും കാണുന്നില്ല |
പ്രവർത്തിക്കുന്ന രൂപം രണ്ട് ജോലികളുള്ള രണ്ട് അതിരുകളാണ്. ആപ്പ് അറിയുന്ന പ്രാദേശിക അതിർ ഫോണിന്റെ പെരുമാറ്റം നിയന്ത്രിക്കുന്നു, നേരിട്ടുള്ള വീഴ്ചയും ഉൾപ്പെടെ, ഗേറ്റ്വേ അതിർ വിദൂര വിഭവങ്ങളെ നിയന്ത്രിക്കുന്നു. ഗേറ്റ്വേ വശത്തിന് ജോലി സേവനം അനുവദിച്ച് മറ്റെല്ലാ സ്വകാര്യ സബ്നെറ്റും നിരസിക്കാം, ഫോൺ വശത്തെ നയം ആപ്പ് എടുത്തേക്കാവുന്ന നേരിട്ടുള്ള പാതയെക്കുറിച്ച് സ്വയം തീരുമാനിക്കുന്നു.
ഘട്ടം 5: ഗതാഗതം ജീവനോടെ നിർത്തി പരിശോധിക്കുക
നിങ്ങൾ ഏത് പ്രാദേശിക നയം തിരഞ്ഞെടുത്താലും, VPN സ്ഥാപിക്കുകയും നിലനിർത്തുകയും ചെയ്യുന്ന ഗതാഗതം അത് അനുവദിക്കണം. ആ ഗതാഗതം തടയുന്നത് ഫോണിനെ ടണലും നയവുമില്ലാതെ വിടുന്നു, അത് ഒന്നും സ്ഥിരതയോടെ നിർവ്വഹിക്കുന്നില്ല, ആപ്പിന് നെറ്റ്വർക്ക് ഇല്ലാത്തതിനാൽ രോഗനിർണ്ണയവും ബുദ്ധിമുട്ടാണ്.
പിന്നീട് പൊതുധാരണയ്ക്ക് പകരം യഥാർത്ഥ വാക്യത്തിന്റെ ഓരോ വരിയും പരിശോധിക്കുക: ജോലി ആപ്പ് ജോലി സേവനത്തിൽ എത്തുന്നു, അതേ ആപ്പ് മറ്റൊരു ലക്ഷ്യത്തിൽ നിരസിക്കപ്പെടുന്നു, ജോലിയല്ലാത്ത ആപ്പ് മുൻപുപോലെ പെരുമാറുന്നു, ടണൽ നിർത്തുമ്പോൾ ജോലി ആപ്പ് നേരിട്ടുള്ള കണക്ഷനിലേക്ക് വീഴുന്നില്ല. DNS പാത വെവ്വേറെ പരിശോധിക്കുക, സ്വകാര്യ DNS അല്ലെങ്കിൽ എൻക്രിപ്റ്റ് ചെയ്ത റിസോൾവർ വിലാസങ്ങൾ മാത്രം പരിശോധിക്കുന്ന ഫിൽട്ടറിനെ മറികടന്നേക്കാം.
ഈ ഘട്ടങ്ങളിൽ ഒന്ന് ഫോണിൽ നിറവേറ്റാനാവില്ലെങ്കിൽ, ആവശ്യകത ആർക്കിടെക്ചർ ചോദ്യമാണ്, ഫയർവാൾ ക്രമീകരണമല്ല. നയം നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഉപകരണത്തിനും ഗേറ്റ്വേക്കും ഇടയിൽ പങ്കിടുന്നതാണ് സാധാരണയായി സത്യസന്ധമായ ഉത്തരം, Android VPN കണക്റ്റിവിറ്റി രേഖകൾ ഒരു സേവനത്തിന് പ്ലാറ്റ്ഫോം എന്ത് അനുവദിക്കും എന്ത് അനുവദിക്കില്ല എന്ന് സ്ഥിരീകരിക്കുന്ന സ്ഥലമാണ്.