സൈറ്റ് ടണൽ മടങ്ങിയെത്തിയതിന് ശേഷമുള്ള ഫാൾബാക്ക് ലീസ്: പുതുക്കണോ അതോ കാത്തിരിക്കണോ?

സൈറ്റ് ലിങ്ക് സജീവമാണ്, ടണൽ സ്ഥാപിതമാണ്, എന്നിട്ടും ബ്രാഞ്ച് കമ്പ്യൂട്ടറുകൾക്ക് ഇപ്പോഴും ഫയൽ സെർവറിൽ എത്താൻ കഴിയുന്നില്ല. തടസ്സത്തിനിടയിൽ രണ്ട് ഘടികാരങ്ങൾ പ്രവർത്തിച്ചിരുന്നു, അവയിൽ ഒന്ന് മാത്രമാണ് പൂർത്തിയായത്. എൻക്രിപ്റ്റ് ചെയ്ത പാത മടങ്ങിയെത്തിയപ്പോൾ ടണൽ പുനഃസ്ഥാപിച്ചു; ഓരോ ക്ലയന്റിന്റെയും വിലാസം അതിന്റെ നിലവിലെ ലീസ് അവസാനിക്കുമ്പോഴോ മാറ്റിസ്ഥാപിക്കുമ്പോഴോ പുനഃസ്ഥാപിക്കുന്നു. ഈ രണ്ട് സമയരേഖകൾ താരതമ്യം ചെയ്യുന്നത് ഫയർവാൾ ലോഗുകൾ വായിക്കുന്നതിനേക്കാൾ വേഗത്തിൽ വിടവ് വിശദീകരിക്കുന്നു.

രണ്ട് ഘടികാരങ്ങൾ, അവയിലൊന്ന് ടണലല്ല

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

നടപ്പാക്കലും സോഫ്റ്റ്വെയർ പതിപ്പും ഈ പ്രസ്താവനയോട് ബന്ധിപ്പിച്ച് നിർത്തുക. ടൈമർ നാമങ്ങളും സ്ഥിരസ്ഥിതി മൂല്യങ്ങളും SonicOS പതിപ്പുകൾക്കിടയിൽ വ്യത്യാസപ്പെടുന്നു, പഴയ ഇന്റർഫേസ് പുതിയത് എന്ത് ചെയ്യുന്നു എന്ന് തെളിയിക്കുന്നില്ല.

രണ്ട് പുനഃസ്ഥാപന നടപടികൾ താരതമ്യം ചെയ്യുക

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

ipconfig /all
ipconfig /release
ipconfig /renew

എന്തെങ്കിലും റിലീസ് ചെയ്യുന്നതിന് മുമ്പ് ഔട്ട്പുട്ട് വായിക്കുക. വിലാസവും ഗേറ്റ്വേയും DNS-ഉം ഇതിനകം സാധാരണ പരിധിയുമായി പൊരുത്തപ്പെടുന്നുവെങ്കിൽ, ക്ലയന്റ് സ്വയം പുനഃസ്ഥാപിക്കപ്പെട്ടു, ബാക്കിയുള്ള പ്രശ്നം മറ്റൊരിടത്താണ്. Linux ക്ലയന്റിൽ തത്തുല്യമായത് കൈകൊണ്ട് തിരുത്തിയ വിലാസമല്ല, നെറ്റ്വർക്ക് മാനേജർ വഴിയുള്ള ലീസ് റിലീസും പുതുക്കലുമാണ്, അല്ലാത്തപക്ഷം മാനേജർ അടുത്ത ഇവന്റിൽ നിങ്ങളുടെ മാറ്റം വീണ്ടും എഴുതും.

ഓഫർ വായിക്കുക, വിലാസം മാത്രമല്ല

വിലാസം മാത്രം അത് ആരാണ് നൽകിയതെന്ന് പറയുന്നില്ല. പ്രധാനമായത് ഓഫറിലെ സെർവർ ഐഡന്റിഫയറും ലീസ് സമയവും, ഗേറ്റ്വേയും റിസോൾവറും ഫാൾബാക്ക് പരിധിയുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ സാധാരണ പരിധിയുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ എന്നതുമാണ്.

tcpdump -ni any 'port 67 or port 68'

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

താരതമ്യം മറിയുന്നയിടം

ഒരേസമയം ധാരാളം ക്ലയന്റുകൾ ബാധിക്കപ്പെട്ടാൽ, ഓരോ ക്ലയന്റിനുമുള്ള പുതുക്കലുകൾ തടസ്സങ്ങളുടെ ഒരു നിരയും ഒരു സപ്പോർട്ട് കോളുമായി മാറുന്നു. ആ സാഹചര്യത്തിൽ ക്ലയന്റുകളെയല്ല, ഫാൾബാക്ക് പരിധിയും പുനഃസ്ഥാപന നടപടിക്രമവും നോക്കുക, കാരണം സമൂഹം ഒരുമിച്ച് പുനഃസ്ഥാപിക്കപ്പെട്ടു, വീണ്ടും ഒരുമിച്ച് പുനഃസ്ഥാപിക്കപ്പെടും.

അയൽക്കാർ കുഴപ്പമില്ലാതിരിക്കുമ്പോൾ ഒരു ക്ലയന്റ് മാത്രം ബാധിക്കപ്പെട്ടാൽ, വിപരീതമാണ് ശരി: ആ ക്ലയന്റിന്റെ ലീസ്, അതിന്റെ റിസർവേഷൻ അല്ലെങ്കിൽ അതിന്റെ സ്വന്തം DHCP ക്ലയന്റിന്റെ സ്വഭാവം ആണ് ചരം, മുഴുവൻ സൈറ്റിലുമുള്ള മാറ്റം തെറ്റായ ഉപകരണമാണ്.

സ്റ്റാറ്റിക് വിലാസങ്ങൾക്കും റിസർവേഷനുകൾക്കും മൂന്നാമത്തെ ഉത്തരം വേണം. ഒരു വിലാസത്തിൽ പിന്നിച്ച ക്ലയന്റിനെ പുതുക്കൽ കൊണ്ട് രക്ഷിക്കാനാവില്ല, ഫാൾബാക്ക് പരിധിയുമായി കൂട്ടിയിടിക്കുന്ന റിസർവേഷൻ, രണ്ട് വിലാസ പ്ലാനുകൾ താരതമ്യം ചെയ്യുന്നതുവരെ റൂട്ടിംഗ് തകരാറിനെപ്പോലെ തോന്നുന്ന ഒരു തനിപ്പകർപ്പ് സൃഷ്ടിക്കുന്നു.

പുറത്തുകടക്കാനുള്ള നടപടിക്രമം എഴുതുക

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

വിലാസമല്ല, വിഭവം സ്ഥിരീകരിച്ചുകൊണ്ട് അവസാനിപ്പിക്കുക. ഫയൽ സെർവറിൽ എത്തുക, അതിന്റെ പേര് പരിഹരിക്കുക, ഇന്റർനെറ്റിൽ എത്തുക എന്നിവ മൂന്ന് വേറിട്ട പരിശോധനകളാണ്, അവസാനത്തേത് മാത്രമാണ് ഒരിക്കലും സംശയത്തിലായിരുന്നില്ല.