വിഭജിത-ടണൽ പട്ടികയേക്കാൾ ലളിതമാണോ മുഴുവൻ ടണലിംഗ്?

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

നിങ്ങൾ പരിപാലിക്കുന്ന നിയമങ്ങൾ എണ്ണിത്തുടങ്ങുക

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

ഓരോ എൻട്രിയും മൂന്ന് ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകണം: അതില്ലാതെ എന്ത് തകരുന്നു, അത് ആരാണ് തീരുമാനിച്ചത്, കാരണം കാലഹരണപ്പെട്ടത് നിങ്ങൾ എങ്ങനെ ശ്രദ്ധിക്കും. മൂന്നിനും ഉത്തരം നൽകാൻ കഴിയാത്ത എൻട്രികൾ കൈമാറ്റത്തിനല്ല, ഇല്ലാതാക്കലിന് സ്ഥാനാർത്ഥികളാണ്, അവ ആദ്യം ഇല്ലാതാക്കുന്നത് പിന്നീടുള്ള താരതമ്യത്തെ സത്യസന്ധമാക്കുന്നു.

മിക്ക എൻട്രികളും ട്രാഫിക്കിന്റെ വലിയ പങ്ക് റൂട്ട് ചെയ്യുന്നുവെങ്കിൽ, നിങ്ങൾ ഇതിനകം പരിപാലന ഭാരത്തോടെയുള്ള മുഴുവൻ ടണൽ പ്രവർത്തിപ്പിക്കുന്നു. അപ്പോൾ തീരുമാനം ഡിഫോൾട്ട് എവിടെ താമസിക്കുന്നു എന്നതിലാണ്, അത് ഉണ്ടാകണമോ എന്നതിലല്ല.

ഗേറ്റ്വേയ്ക്ക് ഡിഫോൾട്ട് വഹിക്കാൻ കഴിയുമോ എന്ന് പരിശോധിക്കുക

മുഴുവൻ ടണലിംഗ് ഓരോ പാക്കറ്റും ഒരു ഉപകരണത്തിലേക്ക് നീക്കുന്നു, അത് ആ ഉപകരണത്തിന്റെ പ്രോസസർ ഭാരം, conntrack പട്ടിക, വിലാസ വിവർത്തനം, അപ്സ്ട്രീം ബാൻഡ്വിഡ്ത്ത് ആവശ്യം എന്നിവ ഒരേസമയം മാറ്റുന്നു. കുറച്ച് ആന്തരിക സബ്നെറ്റുകൾക്ക് സുഖമായി സേവനം നൽകിയ ഗേറ്റ്വേ ഒരു ഉപയോക്താവിന്റെ മുഴുവൻ ബ്രൗസിംഗിനും അളക്കപ്പെട്ടിട്ടുണ്ടാകണമെന്നില്ല. ശരാശരിയല്ല, നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന പരമാവധി ഒരേസമയ സെഷനുകളുടെ എണ്ണം നോക്കുക, കാരണം ആദ്യം തകരുന്നത് കൊടുമുടിയാണ്.

ip -s link show dev tun0
conntrack -C
ss -s

മാറ്റത്തിന് മുൻപും ശേഷവും അതേ ജോലിഭാരം അളക്കുക, സ്പെസിഫിക്കേഷനുകളിൽ നിന്ന് അനുമാനിക്കുന്നതിന് പകരം. ഒരു യന്ത്രത്തിൽ ഒരു ഉച്ചയ്ക്കുശേഷമുള്ള സാധാരണ ഉപയോഗം ഗേറ്റ്വേ ഒരു പരിധിക്ക് അടുത്താണോ എന്ന് കാണിക്കും, തിങ്കളാഴ്ച രാവിലെ അത് കണ്ടെത്തുന്നതിനെക്കാൾ ഇതിന് ഒന്നും ചെലവില്ല.

പാതയുടെ MTU യും തുടക്കം മുതൽ അവസാനം വരെ പരിശോധിക്കുക, കാരണം പൂർണ്ണ ഡിഫോൾട്ട് ഓരോ ആപ്പിനെയും ടണലിന്റെ പരമാവധി പാക്കറ്റ് വലിപ്പത്തിന് വിധേയമാക്കുന്നു. ടണലിന് പുറത്ത് പ്രവർത്തിച്ച ആപ്പുകൾ ഇപ്പോൾ നിങ്ങൾ ഒരിക്കലും പരിഗണിക്കേണ്ടിവന്നിട്ടില്ലാത്ത ശകലീകരണ സ്വഭാവത്തെ ആശ്രയിച്ചേക്കാം.

പ്രാദേശിക സേവനങ്ങളും സ്വകാര്യ DNS ഉം ഇപ്പോഴും പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക

പ്രാദേശികമായി തുടരേണ്ടത് ആപ്പ് പേരനുസരിച്ചല്ല, പ്രോട്ടോക്കോൾ അനുസരിച്ച് പട്ടികപ്പെടുത്തുക: പ്രിന്ററുകൾക്കും ഡിസ്പ്ലേകൾക്കുമുള്ള കണ്ടെത്തൽ പ്രോട്ടോക്കോളുകൾ, സ്മാർട്ട്-ഹോം ബ്രിഡ്ജ്, റൗട്ടറിന്റെ മാനേജ്മെന്റ് പേജ്, LAN ൽ മാത്രം പരിഹരിക്കുന്ന പേരിലൂടെ എത്തുന്ന പ്രാദേശിക വികസന സെർവർ. ഡിഫോൾട്ട് റൂട്ട് ടണലിലേക്ക് ചൂണ്ടാൻ തുടങ്ങുമ്പോൾ ഇവ തകരുന്നു, ക്ലയന്റിൽ ഒന്നും പിശക് രേഖപ്പെടുത്താത്തതിനാൽ നിശ്ശബ്ദമായി തകരുന്നു.

സ്വകാര്യ DNS ആണ് മറ്റൊരു ആശ്രിതത്വം. ആന്തരിക നാമങ്ങൾ മുൻപ് ടണലിന്റെ റിസോൾവർ വഴി പരിഹരിച്ചിരുന്നെങ്കിൽ ഒന്നും മാറുന്നില്ല; പ്രാദേശികമായി പരിഹരിച്ചിരുന്നെങ്കിൽ, പൂർണ്ണ ഡിഫോൾട്ട് അവയെ സോണുകൾ അറിയുന്ന റിസോൾവറിലേക്ക് എത്തിക്കണം. മാറ്റത്തിന് ശേഷം ഒരു ആന്തരികവും ഒരു പൊതുവുമായ നാമം പരീക്ഷിക്കുക, റിസോൾവർ പട്ടിക അതിജീവിച്ചു എന്ന് കരുതുന്നതിന് പകരം.

പ്രാദേശിക ഒഴിവാക്കലുകൾ അവയുടെ ഉടമസ്ഥതയിലുള്ള പ്രൊഫൈലിൽ എഴുതുക. ആരുടെയോ ഓർമ്മയിൽ മാത്രം സൂക്ഷിക്കുന്ന ഒഴിവാക്കലാണ് അടുത്ത കൈമാറ്റത്തിൽ ആദ്യം നഷ്ടപ്പെടുന്നത്.

ഒരു പ്രൊഫൈൽ കൈമാറി അതിരുകൾ സ്ഥിരീകരിക്കുക

മുൻപത്തെ പരീക്ഷണങ്ങൾ വിട്ടേച്ച കൈയാൽ ചെയ്ത റൂട്ടുകൾക്ക് മുകളിൽ പുതിയ ഡിഫോൾട്ട് പാളിയാക്കുന്നതിന് പകരം, പ്രൊഫൈൽ അതിന്റെ സ്വന്തം കോൺഫിഗറേഷനിലൂടെ മാറ്റുക. ആ ബാക്കിയുള്ള റൂട്ടുകളാണ് പ്രവർത്തിക്കുന്നതായി തോന്നി ഒരു ദിവസത്തിന് ശേഷം പൊരുത്തക്കേടോടെ പെരുമാറുന്ന കൈമാറ്റത്തിന്റെ സാധാരണ കാരണം. പഴയ പ്രൊഫൈൽ ലഭ്യമായി സൂക്ഷിക്കുക, തിരിച്ചുപോക്ക് പുനർനിർമ്മാണമല്ല, തിരഞ്ഞെടുപ്പാകട്ടെ.

എന്നിട്ട് രണ്ട് അതിരുകൾ വെവ്വേറെ സ്ഥിരീകരിക്കുക: പൊതു, സ്വകാര്യ ലക്ഷ്യങ്ങൾ രണ്ടും പ്രവർത്തിക്കുന്നു, ആവശ്യമില്ലാത്ത ട്രാഫിക് ടണലിന് പുറത്ത് പോകുന്നില്ല. വിജയകരമായ പേജ് ലോഡ് ആദ്യത്തേത് തെളിയിക്കുന്നു, രണ്ടാമത്തേതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

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