VPN റൂട്ട് കാഷെ നിങ്ങളുടെ മാറ്റം മറയ്ക്കുന്നുണ്ടോ? മൂന്ന് കാര്യങ്ങൾ പരിശോധിക്കുക

മാറ്റം പ്രാബല്യത്തിൽ വരാത്തപ്പോൾ റൂട്ട് കാഷെ ഒഴിവാക്കുന്നതാണ് ആദ്യ പ്രവണത, ആധുനിക Linux-ൽ അത് വ്യർഥമായ പ്രയത്നമാണ്: ആഗോള IPv4 റൂട്ട് കാഷെ വർഷങ്ങൾക്ക് മുൻപ് നീക്കം ചെയ്തു, അതിനാൽ ip route show cache ഒന്നും പ്രിന്റ് ചെയ്യുന്നില്ല, ഒഴിവാക്കാൻ ഒന്നുമില്ല. നിങ്ങളെ വഞ്ചിക്കുന്ന അവസ്ഥ ഒരു പാളി മുകളിലാണ്: socket-ൽ, NAT മാപ്പിംഗിൽ, resolver-ൽ അല്ലെങ്കിൽ പഴയ പ്രൊഫൈൽ വീണ്ടും പ്രയോഗിച്ച നെറ്റ്വർക്ക് മാനേജറിൽ. മൂന്ന് ചോദ്യങ്ങൾ ആ കേസുകളെ വേർതിരിക്കുന്നു: തെറ്റായ വഴി പുതിയ ഫ്ലോയിൽ നിന്നാണോ പഴയ കണക്ഷനിൽ നിന്നാണോ വരുന്നത്, നിങ്ങളുടെ പ്ലാറ്റ്ഫോം റൂട്ടുകൾ കാഷെ ചെയ്യുന്നുണ്ടോ, അവസ്ഥ റൂട്ടിംഗിലാണോ അതിന് മുകളിലാണോ. ഇന്റർഫേസ് റീസെറ്റ് ചെയ്യുന്നതിന് മുൻപ് അവയ്ക്ക് ഉത്തരം നൽകുക.

പരിശോധന ഒന്ന്: പഴയ വഴി പുതിയ ഫ്ലോയിൽ നിന്നാണോ വരുന്നത്?

സ്ഥാപിത കണക്ഷൻ അത് സൃഷ്ടിക്കപ്പെട്ട വഴി നിലനിർത്തുന്നു. അതുകൊണ്ടാണ് ടണലിന് മുകളിലുള്ള SSH സെഷൻ റൂട്ടിംഗ് ടേബിളിന്റെ മാറ്റത്തെ അതിജീവിക്കുന്നത്, പുതിയ സെഷൻ ഉടൻ പുതിയ വഴി സ്വീകരിക്കുന്നത്, «മാറ്റം ഒന്നും ചെയ്തില്ല» എന്നത് പലപ്പോഴും «പഴയ socket ഇപ്പോഴും അത് പിടിച്ചിരിക്കുന്നു» എന്നർഥമാകുന്നതും. ഇതിനകം തുറന്നിരിക്കുന്ന വിൻഡോയല്ല, പുതിയ പ്രോസസ് ഉപയോഗിച്ച് പരീക്ഷിക്കുക.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

അവസാന കമാൻഡ് പുതിയ കണക്ഷൻ യഥാർഥത്തിൽ എത്തിയ വിലാസം പ്രിന്റ് ചെയ്യുന്നു, സ്റ്റാറ്റസ് വിൻഡോയിൽ വിശ്വസിക്കാതെ യഥാർഥ വഴി കാണാനുള്ള ഏറ്റവും ചെലവുകുറഞ്ഞ മാർഗമാണത്. namespace അല്ലെങ്കിൽ ഇന്റർഫേസ് ഉപയോഗിക്കേണ്ടിയിരുന്ന സോഴ്സ് വിലാസവുമായി അതിനെ താരതമ്യം ചെയ്യുക.

പുതിയ ഫ്ലോ ശരിയായ വഴി സ്വീകരിക്കുകയും പഴയത് വീണ്ടെടുക്കാതിരിക്കുകയും ചെയ്താൽ റൂട്ടിംഗ് നോക്കുന്നത് നിർത്തുക. വഴി ശരിയായിരുന്നു; സെഷൻ പഴയതായിരുന്നു.

പരിശോധന രണ്ട്: നിങ്ങളുടെ പ്ലാറ്റ്ഫോം റൂട്ട് കാഷെ സൂക്ഷിക്കുന്നുണ്ടോ?

Linux-ൽ ഉത്തരം ഇല്ല, മിക്ക ഗൈഡുകളും ഉദ്ദേശിക്കുന്ന അർഥത്തിൽ. വലിച്ചെറിയാൻ ആഗോള ലക്ഷ്യ കാഷെ ഇല്ല, തിരഞ്ഞെടുത്ത റൂട്ട് സൂക്ഷിക്കുന്ന socket തലത്തിലുള്ള എൻട്രി socket-നൊപ്പം വിട്ടയക്കുന്നു. ip-route മാനുവലിന്റെ കാഷെ വിഭാഗം ചരിത്രപരമായ സ്വഭാവം വിവരിക്കുന്നു, നിലവിലെ കെർണലിൽ ഒഴിവാക്കാവുന്ന ഒന്നല്ല.

മറ്റ് പ്ലാറ്റ്ഫോമുകൾ വ്യത്യസ്തമാണ്, ഉപദേശങ്ങൾ പകർത്തുന്നത് ഇവിടെയാണ് തെറ്റാകുന്നത്. Windows ഒരു ലക്ഷ്യ കാഷെ സൂക്ഷിക്കുന്നു, അത് netsh interface ip delete destinationcache ഉപയോഗിച്ച് വൃത്തിയാക്കാം. BSD-ഉം macOS-ഉം route -n get വഴി ഓരോ ലക്ഷ്യത്തിനുമുള്ള തിരയലുകൾ കാണിക്കുന്നു, അവയുടെ കാഷെകൾ സ്വന്തം ഷെഡ്യൂൾ പ്രകാരം കാലഹരണപ്പെടുന്നു. ഇവയിലൊന്നിൽ പ്രവർത്തിക്കുന്ന കമാൻഡ് Linux-ൽ ഒന്നും ചെയ്യുന്നില്ല, അതിനാൽ അതേ പരിഹാരം പരീക്ഷിക്കുന്ന പകുതി പേർക്ക് പരാജയമായി തോന്നുന്നു.

NAT അല്ലെങ്കിൽ conntrack ടേബിൾ റൂട്ട് കാഷെയല്ല, എന്നാൽ അതേ ലക്ഷണം ഉണ്ടാക്കുന്നു. നിങ്ങളുടെ മാറ്റത്തിന് മുൻപ് വിവർത്തനം ചെയ്ത ഫ്ലോ അതിന്റെ വിവർത്തനം നിലനിർത്തുന്നു, റൂട്ടിംഗ് നയം മുന്നോട്ട് പോയതിന് ശേഷം വളരെക്കാലം conntrack -L അത് കാണിക്കും. അത് പഴയ അവസ്ഥയാണ്, പക്ഷേ റൂട്ടുകൾ വൃത്തിയാക്കുന്നത് അതിനെ തൊടുകയില്ല.

പരിശോധന മൂന്ന്: അവസ്ഥ റൂട്ടിംഗിലാണോ അതിന് മുകളിലാണോ?

മറ്റെന്തും വായിക്കുന്നതിന് മുൻപ് നിലവിലെ തിരയൽ വായിക്കുക: ലക്ഷ്യത്തിന് ip route get, പിന്നെ from ഉം സോഴ്സ് വിലാസവും ചേർത്ത അതേ കമാൻഡ്, പിന്നെ ip rule show. ഈ മൂന്നും നിങ്ങളുടെ ഉദ്ദേശവുമായി യോജിക്കുന്നുവെങ്കിൽ, റൂട്ടിംഗ് തിരുത്തേണ്ട പാളിയല്ല, പഴയ നിരീക്ഷണം മറ്റൊരിടത്തുനിന്നാണ് വന്നത്.

മൂന്ന് സാധാരണ സംശയിതാക്കൾ റൂട്ടിംഗിന് മുകളിലിരിക്കുന്നു. നെറ്റ്വർക്ക് മാനേജർ നിങ്ങൾ ഇല്ലാതാക്കിയ കുറച്ച് സെക്കൻഡുകൾക്കുള്ളിൽ സേവ് ചെയ്ത പ്രൊഫൈലിൽ നിന്ന് റൂട്ട് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യാം, അതിനാൽ നിങ്ങളുടെ മാറ്റം തിരികെ വരുന്നതായി തോന്നുന്നു; ടേബിൾ വീണ്ടും എഡിറ്റ് ചെയ്യുന്നതിന് മുൻപ് nmcli connection show --active ഉം യൂണിറ്റ് അവസ്ഥയും പരിശോധിക്കുക. Resolver കാഷെ പഴയ വിലാസം തിരികെ നൽകുന്നു, അത് കാഷെ തകർക്കുന്ന ഉപകരണം ഉപയോഗിച്ച് അതേ പേര് ചോദിക്കുന്നത് വരെ റൂട്ടിംഗ് പരാജയം പോലെ തോന്നുന്നു. അപ്ലിക്കേഷന്റെ കണക്ഷൻ പൂൾ പഴയ ലക്ഷ്യത്തിലേക്ക് പ്രവർത്തിക്കുന്ന socket സൂക്ഷിക്കുന്നു, കെർണലിനോട് ഒരിക്കലും പുതിയ തീരുമാനം ചോദിക്കുന്നില്ല.

മൂന്ന് ഉത്തരങ്ങൾ എന്ത് അനുമാനിക്കാൻ അനുവദിക്കുന്നു

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

പൊതുവായ പുതുക്കലിനെ എതിർക്കുക. നെറ്റ്വർക്ക് സ്റ്റാക്ക് പുനരാരംഭിക്കുകയോ ഡിഫോൾട്ട് റൂട്ട് ടണൽ ആയ മെഷീനിൽ എല്ലാ റൂട്ടുകളും ഇല്ലാതാക്കുകയോ ചെയ്താൽ അത് പരിഹരിക്കാൻ ഉപയോഗിക്കുന്ന കണക്ഷൻ തന്നെ മുറിയാം, ഏത് പാളി പരാജയപ്പെട്ടു എന്ന് പറയുമായിരുന്ന തെളിവും നശിപ്പിക്കുന്നു.

ശരിക്കും എന്തെങ്കിലും വൃത്തിയാക്കേണ്ടി വന്നാൽ, രോഗനിർണയവുമായി യോജിക്കുന്ന ഏറ്റവും ചെറിയ കാര്യം വൃത്തിയാക്കുക: ഒരു പ്രോസസിന്റെ socket-കൾ, ഒരു conntrack എൻട്രി, resolver കാഷെ. പിന്നീട് അതേ പുതിയ-ഫ്ലോ പരിശോധന ആവർത്തിച്ച് എന്ത് മാറി എന്ന് എഴുതുക.

നിങ്ങളുടെ കുറിപ്പുകളിൽ മൂന്ന് അവസ്ഥകൾ വേർതിരിച്ച് സൂക്ഷിക്കുക

സേവ് ചെയ്ത കോൺഫിഗറേഷൻ, നിലവിലെ തിരയൽ, നിരീക്ഷിച്ച ഫ്ലോ എന്നിവ മൂന്ന് വ്യത്യസ്ത വസ്തുതകളാണ്, അവയെ «കാഷെ» യിലേക്ക് ചേർക്കുന്നതാണ് തകരാറിനെ വീണ്ടും സൃഷ്ടിക്കാൻ ബുദ്ധിമുട്ടാക്കുന്നത്. റൂട്ടിന്റെ ഉടമയായ പ്രൊഫൈലോ യൂണിറ്റോ, ip route get-ന്റെ ഔട്ട്പുട്ട്, യഥാർഥ കണക്ഷന്റെ സോഴ്സും ലക്ഷ്യവും എഴുതുക.

അവയുടെ അടുത്ത് പ്ലാറ്റ്ഫോമും ക്ലയന്റ് പതിപ്പും രേഖപ്പെടുത്തുക, കാരണം Windows ലക്ഷ്യ കാഷെ വൃത്തിയാക്കുന്ന പരിഹാരം Linux ഹോസ്റ്റിന് ബാധകമായ പരിഹാരമല്ല, രണ്ടിനുമിടയിൽ പകർത്തിയ നടപടിക്രമം തെറ്റായ പാഠം പഠിപ്പിക്കുന്നു. പ്രശ്നം മറ്റൊരാൾക്ക് കൈമാറുമ്പോൾ, ആ മൂന്ന് വരികൾ അയാൾക്ക് ഊഹിക്കുന്നതിന് പകരം പരാജയ അവസ്ഥ വീണ്ടും സൃഷ്ടിക്കാൻ അനുവദിക്കുന്നു.