ഒരേ സമയം രണ്ട് VPN ആപ്പുകൾ: ഏത് kill switch ആണ് യഥാർത്ഥത്തിൽ ബാധകമാകുന്നത്?
രണ്ടാമത്തെ VPN ക്ലയന്റ് ഒരിക്കലും ആദ്യത്തേതിന്റെ kill switch അനന്തരാവകാശമായി നേടുന്നില്ല. ഏത് നയം ബാധകമാകുന്നു എന്ന് മൂന്ന് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു, നിങ്ങളുടേത് എങ്ങനെ പരിശോധിക്കാം.
രണ്ട് VPN ക്ലയന്റുകൾക്ക് സമാന്തരമായി പ്രവർത്തിക്കാം, പക്ഷേ അവയുടെ kill switch ഒരൊറ്റ നയത്തിൽ ലയിക്കുന്നില്ല. ഓരോ ക്ലയന്റും തന്റെ ടണലിനായി നിയമങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു, മറ്റൊന്ന് നിലവിലുണ്ടെന്ന് ഒന്നിനും അറിയില്ല. ജോലിയുടെ ക്ലയന്റ് ആദ്യം കണക്ട് ചെയ്തിരുന്നപ്പോൾ ഞാൻ ഇത് അനുഭവിച്ചു: രണ്ടാമത്തെ ആപ്പിന് തന്റെ ഹാൻഡ്ഷേക്ക് പൂർത്തിയാക്കാനായില്ല, പത്ത് മിനിറ്റ് „Connecting“-ൽ ഇരുന്നു, ആദ്യ ടണൽ എല്ലാം നിശ്ശബ്ദമായി വഹിച്ചു. രണ്ടാമത്തെ ആപ്പ് സംരക്ഷിക്കപ്പെടുമോ എന്നത് മൂന്ന് വ്യവസ്ഥകളെ ആശ്രയിച്ചിരിക്കുന്നു, രണ്ട് ഐക്കണുകളും കണക്ട് ചെയ്തു എന്ന് പറയുന്നതിനെ അല്ല.
kill switch യഥാർത്ഥത്തിൽ എന്തിന് പരിമിതപ്പെട്ടിരിക്കുന്നു
ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ ഒരൊറ്റ kill switch കൊടിയില്ല. അത്തരം കൊടി പ്രചരിപ്പിക്കുന്ന ക്ലയന്റ് ഒരു നിയമക്കൂട്ടം ഇൻസ്റ്റാൾ ചെയ്യുന്നു: എന്റെ ടണലിലൂടെ പുറത്തുപോകാത്തതെല്ലാം വലിച്ചെറിയുക, ടണൽ അപ്രത്യക്ഷമാകുമ്പോൾ പലപ്പോഴും fail closed പെരുമാറുക. Linux-ൽ ഇത് സാധാരണയായി nftables അല്ലെങ്കിൽ iptables ശൃംഖല, Windows-ൽ Windows Filtering Platform ഫിൽട്ടറുകളുടെ കൂട്ടം, Android, iOS-ൽ ടണൽ സേവനത്തിന്റെ സ്വന്തം റൂട്ടിംഗും VPN ഇല്ലാതെ കണക്ഷനുകൾ തടയുന്ന ആ സിസ്റ്റം ക്രമീകരണവും. Android VPN ഗൈഡ് ഈ സേവന മാതൃക വിവരിക്കുന്നു, നിങ്ങൾക്ക് പ്ലാറ്റ്ഫോമിന്റെ കാഴ്ചപ്പാട് വേണമെങ്കിൽ.
പരിധിയാണ് പ്രധാന ഭാഗം. „wg0 ഔട്ട്പുട്ട് ഇന്റർഫേസിൽ പാക്കറ്റുകൾക്ക് മാത്രം അനുവാദം നൽകുക“ എന്ന നിയമം രണ്ടാമത്തെ ടണൽ ഉണ്ടോ എന്ന് ശ്രദ്ധിക്കുന്നില്ല. മറ്റൊരു ക്ലയന്റ് wg1 ഉയർത്തിയാൽ, ആദ്യ ക്ലയന്റിന്റെ നിയമങ്ങൾ ആ പാക്കറ്റുകളെ സാധാരണ ട്രാഫിക്കായി കണക്കാക്കുന്നു: സാധാരണയായി വലിച്ചെറിയപ്പെടുന്നു, ചിലപ്പോൾ അനുവദിക്കപ്പെടുന്നു. ഏതായാലും തീരുമാനം ആദ്യ ക്ലയന്റിന്റേതാണ്, രണ്ടാമത്തെ ആപ്പ് കാത്തിരിക്കുന്നുണ്ടെന്ന് അതിനറിയില്ല.
ആരാണ് പരിരക്ഷിക്കപ്പെടുക എന്ന് തീരുമാനിക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ
ഓരോ സംയോജനവും എണ്ണേണ്ട ആവശ്യമില്ല. മൂന്ന് ചോദ്യങ്ങൾ ഇത് കുറച്ച് മിനിറ്റുകളിൽ തീരുമാനിക്കുന്നു.
- പ്ലാറ്റ്ഫോം രണ്ടാമത്തെ ടണലിന് അനുവാദം നൽകുന്നുണ്ടോ? മിക്ക Android ഫോണുകളും iPhone-കളും ഓരോ ഉപയോക്തൃ പ്രൊഫൈലിനും ഒരു സജീവ VPN സേവനം മാത്രമേ സ്വീകരിക്കുന്നുള്ളൂ, അതിനാൽ രണ്ടാമത്തെ ആപ്പിന് ഒരിക്കലും ടണൽ ഉണ്ടാകില്ല, ഒന്നും നടപ്പാക്കുന്നില്ല. നിങ്ങൾക്ക് ഒരൊറ്റ നയം ലഭിക്കുന്നു, സ്ഥലം നേടിയ ആപ്പിൽ നിന്ന്.
- ഡിഫോൾട്ട് റൂട്ട് ഏത് പ്രോസസ്സിന്റെ ഉടമസ്ഥതയിലാണ്? Windows, macOS, Linux രണ്ട് ടണലുകളും എളുപ്പത്തിൽ വഹിക്കുന്നു. ഡിഫോൾട്ട് റൂട്ട് അവസാനം അല്ലെങ്കിൽ മികച്ച മെട്രിക് ഉപയോഗിച്ച് സജ്ജീകരിച്ച ക്ലയന്റിന്റേതാണ്, മറ്റേ ക്ലയന്റ് കണക്ട് ചെയ്തതെങ്കിലും നിഷ്ക്രിയമാണ്. Linux-ൽ wg-quick-ന്റെ ഡിഫോൾട്ട് റൂട്ട് മോഡ് സ്വകാര്യ പട്ടികയും fwmark നിയമവും ഉള്ള നയാധിഷ്ഠിത റൂട്ടിംഗ് ഉപയോഗിക്കുന്നു, അതിനാൽ രണ്ടാമത്തെ wg-quick ടണൽ ആദ്യത്തേത് മാറ്റുന്നതിനു പകരം ഒരു മത്സര നിയമം ചേർക്കുന്നു.
- രണ്ടാമത്തെ ക്ലയന്റിന് സ്വന്തം സെർവറിൽ എത്താനാകുമോ? ആദ്യത്തെ kill switch ഡിഫോൾട്ട് നിരാകരണമാണെങ്കിൽ, രണ്ടാമത്തെ ആപ്പിന്റെ ബാഹ്യ അന്തിമ പോയിന്റ് വെറും മറ്റൊരു വലിച്ചെറിഞ്ഞ ലക്ഷ്യം മാത്രം. അത് നിശ്ശബ്ദമായി വീണ്ടും ശ്രമിക്കുന്നു, ഒരിക്കലും പിശക് റിപ്പോർട്ട് ചെയ്യുന്നില്ല.
ചെറിയ പതിപ്പ്, പിന്തുണ ത്രെഡുകൾക്കായി:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
ആ വരികളിൽ രണ്ടെണ്ണം സിസ്റ്റം ട്രേയിലെ ഐക്കണിൽ നിന്ന് ഒരേപോലെ കാണപ്പെടുന്നു, അതുകൊണ്ടാണ് ഐക്കൺ ഇവിടെ ലഭ്യമായ ഏറ്റവും മോശം തെളിവ്.
ആദ്യം എന്താണ് പരാജയപ്പെടുന്നത്, അത് എങ്ങനെ കാണപ്പെടുന്നു
മറ്റൊന്ന് ആരോഗ്യകരമായിരിക്കുമ്പോൾ ഒരു ക്ലയന്റ് „Connecting“-ൽ കുടുങ്ങിക്കിടക്കുന്നത് ഏതാണ്ട് എപ്പോഴും അന്തിമ പോയിന്റ് വിശപ്പാണ്: പ്രവർത്തിക്കുന്ന kill switch രണ്ടാമത്തെ ക്ലയന്റിന്റെ സ്വന്തം സെർവറിലേക്കുള്ള ഹാൻഡ്ഷേക്ക് വലിച്ചെറിയുന്നു. ഇത് ചെലവുകുറഞ്ഞ രീതിയിൽ പരിശോധിക്കാൻ ആദ്യ ക്ലയന്റിന്റെ തടയൽ നിയമങ്ങൾ ഒരു ശ്രമത്തേക്ക് നിർത്തുക. രണ്ടാമത്തേത് ഉടനെ കണക്ട് ചെയ്താൽ ചോദ്യത്തിന് ഉത്തരം ലഭിച്ചു.
DNS രണ്ടാമത്തെ പരാജയമാണ്. ക്ലയന്റുകൾ തങ്ങളുടെ ഇന്റർഫേസിനായി റിസോൾവർ കോൺഫിഗറേഷൻ സജ്ജീകരിക്കുന്നു, ചിലർ നേരിട്ട് ആഗോള പട്ടിക തന്നെ മുകളിൽ എഴുതുന്നു. രണ്ട് ടണലുകളും മുകളിൽ ഉള്ളപ്പോൾ ക്വറികൾ ഒരു വശത്തുകൂടി പുറത്തുപോകാം, റിസോൾവർ മറ്റേ വശത്തിനുള്ളതാകും. ഏതെങ്കിലും ആപ്പ് വിച്ഛേദിക്കുക, അവശേഷിക്കുന്നത് എത്തിച്ചേരാനാകാത്ത നെയിം സെർവർ സൂക്ഷിക്കുന്നു: പേജുകൾ ഒരു മിനിറ്റ് നിൽക്കുന്നു, പിന്നീട് വീണ്ടും പരിഹരിക്കപ്പെടുന്നു, VPN ഇപ്പോഴും കണക്ട് ചെയ്തതായി കാണിക്കുന്നു.
മൂന്നാമത്തേത് റൂട്ടുകളുടെ ആന്ദോളനമാണ്. പുനഃസംയോജനങ്ങൾ ഡിഫോൾട്ട് റൂട്ട് പുനഃക്രമീകരിക്കുന്നു, ഇന്റർഫേസിനോട് ബന്ധിപ്പിച്ച kill switch അതിനെ പിന്തുടരുന്നില്ല. ഒരു നിമിഷം മുൻപ് ടണലിൽ ഉണ്ടായിരുന്ന ട്രാഫിക് ഇപ്പോൾ വലിച്ചെറിയൽ നിയമവുമായി പൊരുത്തപ്പെടുന്നു, ഇത് ഉപയോക്താവിന്റെ ഭാഗത്തുനിന്ന് യാദൃച്ഛികമായി പ്രവർത്തനം നിർത്തുന്ന VPN ആയി വായിക്കപ്പെടുന്നു.
യഥാർത്ഥത്തിൽ ഏത് നയമാണ് നിലവിലുള്ളതെന്ന് പരിശോധിക്കുക
ഇത് ഹാനികരമല്ലാത്ത ട്രാഫിക്കോടെ ചെയ്യുക, നിങ്ങൾക്ക് നഷ്ടമാകുമെന്ന് ഭയപ്പെടുന്ന ഒന്നിനോടല്ല.
Linux-ൽ കെർണലിനോട് ചോദിക്കുക ആരാണ് വിജയിക്കുന്നതെന്നും ഫയർവാൾ എന്തിനോട് ബന്ധിക്കുന്നുവെന്നും. ip -4 route show default പുറത്തുപോകുന്ന വഴിയുള്ള ടണലിനെ പേരിടുന്നു. ip rule show നയാധിഷ്ഠിത റൂട്ടിംഗ് കളിയിൽ ഉണ്ടോ എന്ന് കാണിക്കുന്നു. sudo nft list ruleset | grep -n oifname വലിച്ചെറിയലുകൾ ഇന്റർഫേസ് പേരിനോടോ അടയാളത്തോടോ മുഴുവൻ ഔട്ട്പുട്ട് ശൃംഖലയോടോ ബന്ധിച്ചിട്ടുണ്ടോ എന്ന് കാണിക്കുന്നു.
Windows-ൽ അതേ കഥ റൂട്ട് മെട്രിക്കിലും ഫിൽട്ടർ പട്ടികയിലും ജീവിക്കുന്നു: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric, Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". macOS-ൽ, netstat -rn -f inet | head -5, scutil --dns | head -20.
പിന്നീട് ആളുകൾ ഒഴിവാക്കുന്ന ഘട്ടം ചെയ്യുക: ടണൽ ബോധപൂർവ്വം നിർത്തി, പരാജയപ്പെടുമെന്ന് നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന ട്രാഫിക് യഥാർത്ഥത്തിൽ പരാജയപ്പെടുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. കണക്ട് ചെയ്ത ഐക്കൺ ഇന്റർഫേസ് അവസ്ഥയാണ്, നിർവ്വഹണമല്ല.
എപ്പോഴാണ് രണ്ട് ക്ലയന്റുകൾ തെറ്റായ രൂപകൽപ്പന
രണ്ടാമത്തെ ആപ്പിന് പിന്നിലെ ഏക ആവശ്യം കൂടുതൽ സംരക്ഷണമാണെങ്കിൽ അത് നീക്കം ചെയ്യുക. പരസ്പരം സംവദിക്കുന്ന രണ്ട് തടയൽ നയങ്ങൾ ഒന്നിനെക്കാൾ പ്രവചനാതീതമാണ്, ഓരോ പുനഃസംയോജനവും ഒരു വിൽപ്പനക്കാരനും പരിശോധിക്കാത്ത അവസ്ഥയിൽ എത്താനുള്ള അവസരമാണ്.
യഥാർത്ഥത്തിൽ ശൃംഖല ആവശ്യമെങ്കിൽ, ഉദാഹരണത്തിന് വാണിജ്യ ഹോപ്പ് വഴി എത്തുന്ന കോർപ്പറേറ്റ് ഗേറ്റ്‌വേ, ഒരൊറ്റ നിർവ്വഹണ ബിന്ദുവുള്ള രൂപകൽപ്പന തിരഞ്ഞെടുക്കുക. അതിന്റെ അർത്ഥം സാധാരണയായി ശൃംഖലയെ പിന്തുണയ്ക്കുന്ന ഒരു റൗട്ടർ അല്ലെങ്കിൽ ഒരു ക്ലയന്റ്, ഒരേ ഡിഫോൾട്ട് റൂട്ടിനായി മത്സരിക്കുന്ന രണ്ട് ഡെസ്ക്ടോപ്പ് ആപ്പുകളല്ല. നിർവ്വഹിക്കപ്പെടുന്ന ഉപകരണത്തിൽ അനുവദനീയമായ ക്ലയന്റ് നിലനിർത്തി ബാക്കിയെല്ലാം പരിധിക്ക് പുറത്തായി കണക്കാക്കുക, ട്രേയിൽ എന്ത് കാണിച്ചാലും.
രണ്ടും നിലനിർത്തുന്നതിന് മുൻപ് പരിശോധനാ പട്ടിക
പട്ടിക ക്രമത്തിൽ പൂർത്തിയാക്കുക; ആദ്യം പരാജയപ്പെടുന്ന ഇനമാണ് ശരിയാക്കേണ്ടത്.
- കൃത്യമായി ഒരു ക്ലയന്റിന് ഡിഫോൾട്ട് റൂട്ടും റിസോൾവറും ഉണ്ടെന്ന് സ്ഥിരീകരിക്കുക.
- രണ്ടാമത്തെ ക്ലയന്റ് മുകളിൽ നിലനിർത്തണമെങ്കിൽ അതിന്റെ സെർവറിന്റെ അന്തിമ പോയിന്റിന് വ്യക്തമായി അനുവാദം നൽകി ഓരോ ക്ലയന്റ് അപ്ഡേറ്റിനും ശേഷം വീണ്ടും പരിശോധിക്കുക.
- ഏതെങ്കിലും ടണൽ വീഴുമ്പോൾ പ്രതീക്ഷിത ഫലം എഴുതി അതേ സാഹചര്യം പരിശോധിക്കുക.
- പുനരാരംഭത്തിന് ശേഷം പരാജയ പാത പരിശോധിക്കുക, ആരംഭ ക്രമം വ്യത്യസ്തമാകുമ്പോൾ.
- നിർവ്വഹിക്കപ്പെടുന്ന പ്രൊഫൈലിൽ നിർത്തി, എന്തെങ്കിലും ചേർക്കുന്നതിന് മുൻപ് ഉടമയോട് ചോദിക്കുക.
മൂന്നാം ഘട്ടം പരാജയപ്പെട്ടാൽ, സത്യസന്ധമായ ഉത്തരം ഒരു ക്ലയന്റ് മാത്രമാണ് നിങ്ങൾക്ക് നയം നൽകുന്നത് എന്നതാണ്. ആരെ വിശ്വസിക്കുന്നു എന്ന് തീരുമാനിച്ച് മറ്റേതിനെ വിടുക.