ഇൻക്ലൂഡ് മാത്രം അല്ലെങ്കിൽ എക്സ്ക്ലൂഡ് മാത്രം സ്പ്ലിറ്റ് ടണലിംഗ്: ഏതാണ് ഡിഫോൾട്ട്?
പട്ടിക നിർമ്മിക്കുന്നതിന് മുമ്പ് ഡിഫോൾട്ട് തിരഞ്ഞെടുക്കുക: നിങ്ങൾ പേരിടുന്നത് മാത്രം ടണലിലൂടെ അയക്കുക, അല്ലെങ്കിൽ എല്ലാം അയച്ച് ഒഴിവാക്കലുകൾ വെട്ടിയെടുക്കുക. പിന്നീട് ആരും പട്ടികയിൽ ചേർക്കാത്ത ആപ്പ് പരീക്ഷിക്കുക.
നിങ്ങളുടെ VPN ക്ലയന്റിന്റെ റൂട്ടിംഗ് വിഭാഗം തുറന്നാൽ, പലപ്പോഴും ഒരേ ലേബൽ ധരിക്കുന്ന, രൂപം വ്യത്യസ്തമായ രണ്ട് നിയന്ത്രണങ്ങൾ കാണാം. ഒന്ന് ടണലിൽ വേണ്ട ലക്ഷ്യസ്ഥാനങ്ങൾ പട്ടികപ്പെടുത്താൻ ആവശ്യപ്പെടുന്നു, ബാക്കിയെല്ലാം പ്രാദേശിക നെറ്റ്വർക്ക് ഉപയോഗിച്ചുകൊണ്ടിരിക്കുന്നു. മറ്റൊന്ന് എല്ലാം ടണലിലൂടെയാണെന്ന് കരുതി, എന്താണ് പുറത്തേക്ക് വെട്ടിയെടുക്കേണ്ടതെന്ന് ചോദിക്കുന്നു. രണ്ടും ആദ്യ പരിശോധനയിൽ പ്രവർത്തിക്കുന്ന ടണൽ നൽകുന്നു, രണ്ടും പട്ടികയിൽ വരികൾ ചേർത്താണ് പരിപാലിക്കുന്നത്, അതിനാൽ ആരെങ്കിലും പുതിയത് ഇൻസ്റ്റാൾ ചെയ്യുന്നതുവരെ വ്യത്യാസം അദൃശ്യമായി തുടരുന്നു.
ഇത് ഫീച്ചറല്ല, ഡിഫോൾട്ടിന്റെ തിരഞ്ഞെടുപ്പാണ്. പട്ടികയിൽ ഇരുപത് ഇനങ്ങൾ ആകുന്നതിന് മുമ്പ് തീരുമാനിക്കുക.
ഡിഫോൾട്ട് ബ്രോഷറിൽ നിന്നല്ല, ക്ലയന്റിൽ നിന്ന് വായിക്കുക
WireGuard-ൽ ഈ തീരുമാനം അസാധാരണമാംവിധം ദൃശ്യമാണ്, കാരണം AllowedIPs ഒരു ഇൻക്ലൂഡ് പട്ടിക മാത്രമാണ്, മറ്റൊന്നുമല്ല. 0.0.0.0/0, ::/0 ഉള്ള പിയർ എല്ലാം ടണൽ ചെയ്യുന്നു, 10.20.0.0/16 ഉള്ള പിയർ ആ നെറ്റ്വർക്ക് മാത്രം ടണൽ ചെയ്യുന്നു. എക്സ്ക്ലൂഡ് സിന്റാക്സ് ഇല്ലാത്തതിനാൽ ഒരു സബ്നെറ്റ് പുറത്ത് നിർത്തണമെങ്കിൽ ബാക്കി എല്ലാ പ്രിഫിക്സുകളും എണ്ണേണ്ടിവരും, അല്ലെങ്കിൽ ഇന്റർഫേസിന് പുറത്ത് പോളിസി റൂട്ടിംഗ് ചേർക്കണം.
OpenVPN എതിർദിശയിൽ നിന്ന് അതേ സ്ഥലത്ത് എത്തുന്നു: redirect-gateway def1 പൂർണ്ണ ടണൽ സ്ഥാപിക്കുന്നു, പ്രത്യേക route നിർദ്ദേശങ്ങൾ നിർദ്ദിഷ്ട പ്രിഫിക്സുകൾ ചേർക്കുകയോ മാറ്റിയെഴുതുകയോ ചെയ്യുന്നു. വാണിജ്യ ക്ലയന്റുകൾ സാധാരണയായി രണ്ടും ചെക്ക് ബോക്സിനും ലക്ഷ്യസ്ഥാന പട്ടികയ്ക്കും പിന്നിൽ ഒളിപ്പിക്കുന്നു, അതിനാൽ ലേബൽ വിശ്വസിക്കുന്നതിന് മുമ്പ് പട്ടിക യഥാർത്ഥത്തിൽ ഏതാണ് തിരുത്തുന്നതെന്ന് വായിക്കുക.
ചോദിക്കേണ്ടത് ചെക്ക് ബോക്സിന്റെ പേരല്ല. രണ്ട് പട്ടികകളിലും ഇല്ലാത്ത ലക്ഷ്യസ്ഥാനമുള്ള പാക്കറ്റിന് എന്ത് സംഭവിക്കുന്നു എന്നതാണ്. അത് എഴുതി ഉത്തരം നൽകിയാൽ ബാക്കി കോൺഫിഗറേഷൻ അതിൽ നിന്ന് ഉരുത്തിരിയും. ഈ ചോദ്യം ഒഴിവാക്കിയാൽ, ആദ്യത്തെ വിശദീകരിക്കാനാകാത്ത തകരാർ അന്ന് ക്ലയന്റിനോട് ഏറ്റവും അടുത്തുള്ളയാൾ തീരുമാനിക്കും.
ആരും പട്ടികയിൽ ചേർക്കാത്ത ആപ്പ് പിന്തുടരുക
ഇൻക്ലൂഡ് മാത്രം രൂപകൽപ്പനയിൽ ആ ആപ്പ് പ്രാദേശിക നെറ്റ്വർക്കിലൂടെയും പ്രാദേശിക DNS ഉപയോഗിച്ചും നേരിട്ട് പോകുന്നു. എക്സ്ക്ലൂഡ് മാത്രം രൂപകൽപ്പനയിൽ അത് സെർവർ അനുവദിക്കുന്ന പരിധിവരെ ടണലിലൂടെ പോകുന്നു, പുതിയ SaaS ഉപകരണം ആദ്യ ദിവസം തന്നെ പ്രവർത്തിക്കുന്നതും VPN അത് തകർത്തു എന്ന ടിക്കറ്റും തമ്മിലുള്ള വ്യത്യാസം പലപ്പോഴും ഇവിടെയാണ്.
ഏത് ഡിഫോൾട്ടും സ്വയം കൂടുതൽ സുരക്ഷിതമല്ല. ഇൻക്ലൂഡ് മാത്രം ടണൽ ചുമക്കുന്നത് ചുരുക്കി പ്രാദേശിക നെറ്റ്വർക്കിനെ ഏറ്റവും കുറഞ്ഞ പ്രതിരോധത്തിന്റെ വഴിയാക്കുന്നു, എക്സ്ക്ലൂഡ് മാത്രം ടണലിനെ സാധാരണ വഴിയായി കണക്കാക്കി ഒഴിവാക്കലുകളെ ഒഴിവാക്കലുകളായി കാണുന്നു, അത് മിക്ക കോർപ്പറേറ്റ് നയങ്ങളും യഥാർത്ഥത്തിൽ ഉദ്ദേശിക്കുന്നതിന് അടുത്താണ്.
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
പ്ലാറ്റ്ഫോം ഏത് തരം വസ്തുക്കളാണ് പട്ടികപ്പെടുത്തുന്നതെന്ന് ശ്രദ്ധിക്കുക
Android-ന്റെ VpnService.Builder അനുവദിച്ച ആപ്പ് പട്ടികയും വിലക്കിയ ആപ്പ് പട്ടികയും രണ്ട് വേറിട്ട മാതൃകകളായി അവതരിപ്പിക്കുന്നു, ആപ്പ് അടിസ്ഥാനമാക്കിയ നിയമങ്ങൾ ലക്ഷ്യസ്ഥാനത്തിന് പകരം പാക്കേജ് പ്രകാരം തിരഞ്ഞെടുക്കുന്നു. അത്തരം പട്ടികയിൽ ഇട്ട ബ്രൗസർ തുറക്കുന്ന എല്ലാ ലക്ഷ്യസ്ഥാനവും കൊണ്ടുനടക്കുന്നു, അത് റൂട്ട് പട്ടികയിൽ നിന്ന് വ്യത്യസ്തമായ സൂക്ഷ്മതയാണ്, പ്രവർത്തിക്കുന്ന ആപ്പിനുള്ളിലെ ഒരു തകർന്ന സൈറ്റ് പോലും അതിന് ശരിയാക്കാനാവില്ല.
ഡെസ്ക്ടോപ്പ് ക്ലയന്റുകൾ സാധാരണയായി രണ്ട് തരവും ഒരേ ഇന്റർഫേസിൽ കലർത്തുന്നു, അതിനാൽ നിങ്ങൾ ചേർക്കുന്ന വരി ഒരു പാക്കേജാണോ, ഹോസ്റ്റ് നാമമാണോ, പ്രിഫിക്സാണോ എന്ന് പരിശോധിക്കുക. അവ വ്യത്യസ്ത രീതിയിൽ പരാജയപ്പെടുന്നു, വ്യത്യസ്ത സ്ഥലത്താണ് പരിഹരിക്കുന്നത്. ഹോസ്റ്റ് നാമത്തിന്റെ വരി സാധാരണയായി ഒരു റൂട്ടും പേരുമാകുന്നു, പാക്കേജിന്റെ വരി ക്ലയന്റിനുള്ളിലെ പോളിസി തീരുമാനമാകുന്നു. ഏതാണ് ചേർത്തതെന്ന് എഴുതിവയ്ക്കുക, കാരണം പിന്നീട് ഡീബഗ് ചെയ്യുന്നയാൾ മറ്റൊന്നായിരിക്കുമെന്ന് കരുതും.
സന്തോഷകരമായ വഴി മാത്രമല്ല, പരാജയാവസ്ഥയും പരിശോധിക്കുക
ടണലിൽ നിന്ന് ഒഴിവാക്കിയ ആപ്പിന് സ്വയം വൃത്തിയുള്ള നേരിട്ടുള്ള പ്രവേശനം ലഭിക്കുന്നില്ല. ക്ലയന്റ് VPN ഇല്ലാതെ ബ്ലോക്ക് ചെയ്യുന്ന നിയമവും നടപ്പാക്കുന്നുണ്ടെങ്കിൽ, ഒഴിവാക്കിയ ട്രാഫിക് പൂർണ്ണമായും ഉപേക്ഷിക്കപ്പെടാം, അത് റൂട്ടിംഗ് തീരുമാനമല്ല, തകർന്ന ആപ്പ് പോലെ തോന്നും. ഉപയോക്താവിന്റെ പരാതിയിൽ നിന്ന് കണ്ടെത്തുന്നതിന് പകരം ആ സാഹചര്യം ബോധപൂർവ്വം പരിശോധിക്കുക.
തുടർന്ന് DNS-ഉം IPv6-ഉം വേറിട്ട ഇനങ്ങളായി പരിശോധിക്കുക. IPv4 മാത്രം ചുമക്കുന്ന ടണൽ v6 കഴിവുള്ള ആപ്പിന് ചുറ്റും പോകാനുള്ള വഴി ബാക്കിയാക്കുന്നു, split DNS ടണലിലൂടെ പോകാത്ത ട്രാഫിക്കിന് ആന്തരിക നാമങ്ങൾ പരിഹരിക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു. പട്ടികയിലുള്ള ആപ്പ്, പട്ടികയില്ലാത്ത ആപ്പ്, ഒരു നാമ അന്വേഷണം, ഒരു പുനഃസംയോജനം എന്നിവ ഓടിച്ച് ഫലങ്ങൾ കോൺഫിഗറേഷനൊപ്പം സൂക്ഷിക്കുക.
അടുത്തയാൾ കണ്ടെത്തുന്നിടത്ത് ഡിഫോൾട്ട് എഴുതിവയ്ക്കുക
തിരഞ്ഞെടുത്ത ഡിഫോൾട്ടും ഒഴിവാക്കലുകളും അവയുടെ ഉടമയും ക്ലയന്റ് പ്രൊഫൈൽ ഉള്ള അതേ സ്ഥലത്ത് രേഖപ്പെടുത്തുക, കാരണം അടുത്ത അഡ്മിനിസ്ട്രേറ്റർ ഈ ന്യായീകരണം വായിക്കാതെ ഒരു ഇനം ചേർക്കും. തീയതിയും ഓരോ ഒഴിവാക്കലിന്റെയും കാരണവും കുറിക്കുക, അപ്പോൾ പിന്നീട് ശരിയാക്കിയ സൈറ്റിനുള്ള പഴയ ഒഴിവാക്കൽ ഉറപ്പോടെ നീക്കാം. കാരണമില്ലാത്ത പട്ടിക അനന്തമായി വളരും.
ഒരു തകർന്ന ലക്ഷ്യസ്ഥാനം ആരെങ്കിലും റിപ്പോർട്ട് ചെയ്താൽ, അടിത്തറയല്ല, ഒഴിവാക്കൽ മാറ്റുക. ഒരു സൈറ്റ് ശരിയാക്കാൻ ഡിഫോൾട്ട് മറിച്ചിടുന്നത് പട്ടികയില്ലാത്ത എല്ലാ ആപ്പിനെയും നിശബ്ദമായി ടണലിന്റെ മറുവശത്തേക്ക് മാറ്റുന്നു.