Always-on ഉം kill switch ഉം ഒരേ സെറ്റിംഗ്സ് സ്ക്രീനിൽ രണ്ട് വരി അകലത്തിൽ നിൽക്കുന്നു, അതിനാൽ ആളുകൾ അവയെ ഒരേ സവിശേഷതയുടെ രണ്ട് പേരുകളായി വായിക്കുന്നു. അവ അങ്ങനെയല്ല. Always-on ഒരു പുനർബന്ധന നയമാണ്: ബൂട്ടിൽ ടണൽ തുടങ്ങുക, ക്രാഷിനോ നെറ്റ്വർക്ക് മാറ്റത്തിനോ ശേഷം അത് തിരികെ കൊണ്ടുവരിക, പരാജയപ്പെടുമ്പോൾ വീണ്ടും ശ്രമിക്കുക. Kill switch ഒരു ട്രാഫിക് നയമാണ്: ടണൽ ഇല്ലാത്തപ്പോൾ ഏത് പാക്കറ്റുകൾക്ക് ഇപ്പോഴും മെഷീൻ വിടാം എന്ന് അത് പേരിടുന്നു. രണ്ടാമത്തേതില്ലാതെ ആദ്യത്തേത് ഓണാക്കാം, ഒപ്പം മിക്ക പ്ലാറ്റ്ഫോമുകളിലും സ്വതവേയുള്ള ഫലം ആ ഇടവേളയിലും ട്രാഫിക് പുറത്തുപോകാൻ അനുവദിക്കുന്നു.

പരിശോധന 1: ബ്ലോക്ക് സ്വന്തം സ്വിച്ചാണോ?

Android 10 മുതൽ, സേവ് ചെയ്ത VPN പ്രൊഫൈൽ ഗിയർ ഐക്കണിന് പിന്നിൽ രണ്ട് സ്വതന്ത്ര ടോഗിളുകൾ തുറക്കുന്നു: Always-on VPN ഉം Block connections without VPN ഉം. kill switch രണ്ടാമത്തേത് മാത്രമാണ്. always-on മാത്രമുള്ളപ്പോൾ ടണൽ വീണതിന് ശേഷം തിരികെ വരും, അതുവരെ അഭ്യർത്ഥനയുടെ നടുവിലുള്ള ഏത് ആപ്പിനും Wi-Fi അല്ലെങ്കിൽ മൊബൈൽ ഡാറ്റ വഴി നെറ്റ്വർക്കിൽ എത്താം.

നിർവ്വഹിത ഉപകരണങ്ങൾ നയ API-യിൽ അതേ വിഭജനം നിലനിർത്തുന്നു. setAlwaysOnVpnPackage() പാക്കേജ് നാമവും lockdownEnabled ഫ്ലാഗും എടുക്കുന്നു; പാക്കേജ് സെറ്റ് ചെയ്ത് ഫ്ലാഗ് false ആയി വിടുന്ന അഡ്മിൻ സ്ഥിരമായ ടണൽ നിർമ്മിച്ചു, അടച്ച ഉപകരണമല്ല. കൺസോളിലെ പദപ്രയോഗം ആ വ്യത്യാസം വിരളമായി മാത്രമേ കാണിക്കുന്നു.

അവസ്ഥ ഉപകരണത്തിൽ നിന്ന് വായിക്കുക, കൺസോളിൽ നിന്നല്ല: adb shell settings get global always_on_vpn_app ഉം adb shell settings get global always_on_vpn_lockdown ഉം. ആദ്യത്തേത് null നൽകുന്നെങ്കിൽ പ്ലാറ്റ്ഫോം തലത്തിൽ ഒരു പാക്കേജും നിർബന്ധമാക്കിയിട്ടില്ല; രണ്ടാമത്തേത് 0 നൽകുന്നെങ്കിൽ പ്ലാറ്റ്ഫോം ഒന്നും ബ്ലോക്ക് ചെയ്യുന്നില്ല. Android VPN ഗൈഡ് ഇവയെ ഒരു മോഡല്ല, വേറിട്ട കഴിവുകളായി വിവരിക്കുന്നു.

പരിശോധന 2: ബ്ലോക്ക് ഏത് പാളിക്കാണ്?

ലേബലുകൾ ക്ലയന്റിലും ബ്ലോക്കുകൾ സാധാരണയായി ഫയർവാളിലും താമസിക്കുന്നു, അതുകൊണ്ടാണ് ഒരേ വാക്ക് ഓരോ പ്ലാറ്റ്ഫോമിലും വ്യത്യസ്ത അർത്ഥം നൽകുന്നത്. താഴെയുള്ള വരികൾ ഏതെങ്കിലും ഒന്നിനെ വിശ്വസിക്കുന്നതിന് മുൻപ് സ്ഥിരീകരിക്കേണ്ടവയാണ്.

Where you see the labelWhat the label promisesWhat actually blocks
Android VPN profileAlways-on VPNBlock connections without VPN
Android device policyAlways-on packagelockdownEnabled flag
Windows built-in VPNAlways On tunnelOutbound firewall rules
WireGuard for WindowsTunnel serviceBlock untunneled traffic option
wg-quick on LinuxRoute via AllowedIPsYour own nftables or iptables rules

ബ്ലോക്ക് ചെയ്യാത്ത ലേബലിന്റെ ഏറ്റവും വ്യക്തമായ ഉദാഹരണമാണ് Windows. അവിടെ Always On ടണലിന്റെ സ്ഥിരതയെ വിവരിക്കുന്നു: മെഷീൻ പ്രാമാണീകരണത്തിനുള്ള ഡിവൈസ് ടണലും സൈൻ ഇൻ ചെയ്ത അക്കൗണ്ടിനുള്ള യൂസർ ടണലും, പ്രൊഫൈൽ XML അല്ലെങ്കിൽ Add-VpnConnection വഴി ക്രമീകരിക്കുന്നു. ടണൽ ഇല്ലാത്തപ്പോൾ പുറത്തുപോകുന്ന പാക്കറ്റിനെ തടയുന്ന ഒന്നും ആ പ്രൊഫൈലിൽ ഇല്ല, പുറത്തേക്കുള്ള ഫിൽട്ടറിംഗ് സ്വതവേ ഓണല്ല, അതിനാൽ Wi-Fi-ലുള്ള ലാപ്ടോപ്പ് VPN താഴെയായിരിക്കുമ്പോഴും പ്രവർത്തിക്കുന്നു.

WireGuard ഇതേ രീതിയിൽ പിരിയുന്നു, പക്ഷേ ക്ലയന്റ് അനുസരിച്ച്. WireGuard for Windows-ൽ ഓരോ ടണലിനും ഫിൽട്ടർ നിയമങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുന്ന Block untunneled traffic ഓപ്ഷൻ ഉണ്ട്; Linux ടൂളുകൾക്ക് അത്തരം സ്വിച്ച് ഇല്ല. wg-quick ഓരോ AllowedIPs എൻട്രിക്കും ഒരു റൂട്ടും ഒരു fwmark നിയമവും ചേർക്കുന്നു, wg-quick down രണ്ടും നീക്കുന്നു, അതിനാൽ ഭൗതിക ഡിഫോൾട്ട് റൂട്ട് ഒരു പാക്കറ്റും നഷ്ടപ്പെടാതെ വീണ്ടും ഏറ്റെടുക്കുന്നു.

Apple പ്ലാറ്റ്ഫോമുകളിൽ always-on മേൽനോട്ടത്തിലുള്ള ഉപകരണങ്ങൾക്കുള്ള മാനേജ്മെന്റ് പ്രൊഫൈൽ സവിശേഷതയായി വരുന്നു, ചെക്ക്ബോക്സല്ല, on-demand നിയമങ്ങളായി പ്രകടമാകുന്നു. പേലോഡിൽ നിന്ന് ഉത്തരം നൽകേണ്ട ചോദ്യം പരാജയപ്പെട്ട ടണൽ ട്രാഫിക് നിഷേധിക്കുന്നുണ്ടോ അതോ മറ്റൊരു കണക്ഷൻ മാത്രം ആവശ്യപ്പെടുന്നുണ്ടോ എന്നതാണ്. മെനു ശീർഷകം അത് പറയില്ല.

പരിശോധന 3: ഐക്കണല്ല, ഇടവേള അളക്കുക

നാല് പരിവർത്തനങ്ങൾ പ്രധാനമാണ്, അവ വ്യത്യസ്ത രീതിയിൽ പരാജയപ്പെടുന്നു: ആരും ലോഗിൻ ചെയ്യുന്നതിന് മുൻപുള്ള ബൂട്ട്, സ്ലീപ്പും ഉണർവും, Wi-Fi-ൽ നിന്ന് മൊബൈൽ ഡാറ്റയിലേക്കുള്ള മാറ്റം, കൂടാതെ ടണൽ ഇന്റർഫേസ് പകുതി കോൺഫിഗർ ചെയ്ത് വിടുന്ന ക്ലയന്റ് ക്രാഷ്. അവയിലൊന്നിൽ വ്യക്തമായ പുനർബന്ധനം മറ്റ് മൂന്നിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.

ഏറ്റവും വിലകുറഞ്ഞ പരിശോധന ബോധപൂർവം ടണൽ നിർത്തി പുറത്തുപോകാൻ ശ്രമിക്കുന്നു. ടണൽ താഴെയായിരിക്കുമ്പോൾ curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com 200 നൽകുന്നെങ്കിൽ നയം fail-open ആണ്; സമയപരിധി അല്ലെങ്കിൽ നിരസിച്ച കണക്ഷൻ എന്നാൽ എന്തോ ഇപ്പോഴും ബ്ലോക്ക് ചെയ്യുന്നു. ip route get 1.1.1.1 പാക്കറ്റ് കൊണ്ടുപോകുന്ന ഇന്റർഫേസ് പേരിടുന്നു, അത് സാധാരണയായി ട്രേ ഐക്കണിനെക്കാൾ വിവരദായകമാണ്, systemctl status wg-quick@wg0 ഇന്റർഫേസ് വ്യക്തമായി നീക്കിയോ എന്ന് കാണിക്കുന്നു.

അതേ പരിശോധന നെറ്റ്വർക്ക് മാറിക്കൊണ്ടിരിക്കുമ്പോൾ രണ്ടാമത്തെ വിൻഡോയിൽ പ്രവർത്തിപ്പിക്കുക, അത് സ്ഥിരപ്പെട്ടതിന് ശേഷം മാത്രമല്ല. വീഴ്ചയും വീണ്ടും ശ്രമവും തമ്മിലുള്ള ഇടവേളയാണ് പ്രധാനം, പേര് നിർണ്ണയം ട്രാഫിക് രക്ഷപ്പെട്ടു എന്ന് തിരിച്ചറിയാനുള്ള വേഗതയേറിയ വഴിയാണ്: ടണൽ താഴെയായിരിക്കുമ്പോൾ പ്രാദേശിക റിസോൾവർ ഉത്തരം നൽകുന്നെങ്കിൽ ബ്ലോക്ക് പൂർണ്ണമല്ല.

പരിശോധന 4: ലോക്ക് ചെയ്യുന്നതിന് മുൻപ് ഒഴിവുകൾ തീരുമാനിക്കുക

രണ്ട് ഒഴിവുകൾ ഘടനാപരമാണ്. ക്ലയന്റ് VPN സെർവറിലേക്ക് തന്നെ എത്തണം, അതിനാൽ എല്ലാം ഉപേക്ഷിക്കുന്ന നിയമക്കൂട്ടം സംരക്ഷണം തിരികെ കൊണ്ടുവരുന്ന പുനർബന്ധനത്തെയും തടയുന്നു. Captive portal-ലേക്കും ഉയർത്തിയിട്ടില്ലാത്ത ടണലിലൂടെ എത്താനാവില്ല, അതിനാൽ ഹോട്ടൽ Wi-Fi-ൽ ലോക്ക് ചെയ്ത ഉപകരണത്തിന് പോർട്ടൽ തുറക്കാനുള്ള രേഖപ്പെടുത്തിയ വഴി വേണം, മെച്ചപ്പെടുത്തിയതല്ല.

ഏറ്റവും ചെറിയ രൂപം, എൻഡ്പോയിന്റ് അനുവദിച്ചതും ബാക്കിയെല്ലാം ഉപേക്ഷിച്ചതും:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

ആ എൻഡ്പോയിന്റ് വരിയെ സ്ഥിരാങ്കമല്ല, ചരം ആയി കാണുക. ദാതാക്കൾ വിലാസങ്ങൾ മാറ്റുന്നു, കാലഹരണപ്പെട്ട ഒഴിവാണ് പ്രവർത്തിക്കുന്ന kill switch പുനർബന്ധിക്കാനാവാത്ത ഉപകരണമാകാനുള്ള സാധാരണ കാരണം. പ്രാദേശിക പ്രിന്ററുകൾ, NAS പങ്കിടലുകൾ, വികസന സേവനങ്ങൾ എന്നിവ അതേ എഴുതിയ ലിസ്റ്റിൽ വരണം, അല്ലെങ്കിൽ അവ ഓരോ സപ്പോർട്ട് ടിക്കറ്റിലും കണ്ടെത്തപ്പെടും.

പരിശോധന 5: യഥാർത്ഥത്തിൽ എന്ത് തെളിയിച്ചു എന്ന് രേഖപ്പെടുത്തുക

നാല് കോളം ഉള്ള പട്ടിക സൂക്ഷിച്ച് പരിശോധനയിലൂടെ നിറയ്ക്കുക: അവസ്ഥ, പ്രതീക്ഷിത സ്വഭാവം, നിരീക്ഷിച്ച സ്വഭാവം, തെളിവ്. വരികൾ പരിശോധന 3-ലെ പരിവർത്തനങ്ങളും ഒരു ബോധപൂർവ പരാജയവുമാണ്. കമാൻഡ് ഔട്ട്പുട്ട് കൊണ്ട് നിറയ്ക്കാനാവാത്ത വരി നിങ്ങൾ പരിശോധിക്കാത്ത വരിയാണ്, പുനർബന്ധന വരി കടന്ന് ബൂട്ട് വരിയിൽ പരാജയപ്പെടുന്ന ഉപകരണം മതിയായത്ര സാധാരണമാണ്, അതിനാൽ അധിക പത്ത് മിനിറ്റ് മൂല്യമുള്ളതാണ്.

ഇത് പൂർത്തിയായി എന്ന് പറയുന്നതിന് മുൻപ്:

  • ബ്ലോക്കിംഗ് ക്രമീകരണം പുനർബന്ധന ക്രമീകരണത്തിൽ നിന്ന് വേറിട്ടതാണെന്ന് ഉറപ്പാക്കി അതിന്റെ മൂല്യം ഉപകരണത്തിൽ വായിക്കുക.
  • ബ്ലോക്ക് ഏത് പാളി നടപ്പാക്കുന്നു - ക്ലയന്റ് ഓപ്ഷൻ, ഡിവൈസ് നയം അല്ലെങ്കിൽ ഫയർവാൾ - എന്നും ആ പാളി എവിടെ ക്രമീകരിക്കുന്നു എന്നും അറിയുക.
  • ബ്ലോക്ക് തെളിയിക്കുന്ന ഒരു പരിശോധന കമാൻഡ് സൂക്ഷിച്ച്, പരിവർത്തന സമയത്ത് പ്രവർത്തിപ്പിക്കുക, അതിന് ശേഷമല്ല.
  • ഒഴിവുകളുടെ ലിസ്റ്റ്, എൻഡ്പോയിന്റ് ഉൾപ്പെടെ, എഴുതി അത് ആരാണ് പുതുക്കുന്നതെന്ന് രേഖപ്പെടുത്തുക.
  • നിർവ്വഹിത ഹാർഡ്വെയറിൽ നിർബന്ധിത നയം വെറുതെ വിടുക; ബ്ലോക്ക് നീക്കുന്നത് ടണൽ നന്നാക്കുന്നതിന് പകരം ആവശ്യകത മാറ്റുന്നു.

അനുബന്ധ ലേഖനങ്ങൾ