keepalive വീണ്ടും കണക്ട് ചെയ്യലല്ല: നിങ്ങൾക്കുള്ള പരാജയം അനുസരിച്ച് തിരഞ്ഞെടുക്കുക

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

മാപ്പിംഗ് പ്രശ്നമാകുമ്പോൾ

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

ഈ ക്രമീകരണങ്ങൾ പ്രോട്ടോക്കോളുകൾക്കിടയിൽ പരസ്പരം മാറ്റാനും കഴിയില്ല. IKEv2-ന്റെ മരിച്ച പങ്കാളി നയം, OpenVPN-ന്റെ ping ടൈമർ, WireGuard-ന്റെ keepalive എന്നിവ ഒരേ ചോദ്യത്തിന് മൂന്ന് വ്യത്യസ്ത സിന്റാക്സും മൂന്ന് വ്യത്യസ്ത ഡിഫോൾട്ടുകളും കൊണ്ട് ഉത്തരം നൽകുന്നു, അതിനാൽ അവയ്ക്കിടയിൽ സംഖ്യ പകർത്തുന്നത് ട്യൂണിംഗിന്റെ വേഷത്തിലുള്ള ഊഹമാണ്.

ബന്ധം നഷ്ടപ്പെട്ടപ്പോൾ

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

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

രണ്ടും എന്ത് തെളിയിക്കുന്നില്ല

ടണൽ വീണ്ടും കണക്ട് ചെയ്ത് കീകളും റൂട്ടുകളുമായി ഇരിക്കാം, പക്ഷേ അതിന് പിന്നിലെ സേവനം പ്രവർത്തിക്കുന്നില്ലായിരിക്കാം, കൂടാതെ keepalive മണിക്കൂറുകൾക്ക് മുമ്പ് സർവർ പോയ സെഷനുവേണ്ടി മാപ്പിംഗ് തുറന്ന് നിർത്താം. നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ പ്രധാനമായ കാര്യം ലഭ്യമല്ലാത്തപ്പോൾ രണ്ട് മെക്കാനിസങ്ങൾക്കും വിജയം റിപ്പോർട്ട് ചെയ്യാം.

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

നേരിട്ടുള്ള ട്രാഫിക് തടയുന്നത് വേറെ തീരുമാനമാണ്

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

ഏത് മെക്കാനിസം പ്രവർത്തിച്ചു, പിന്നീട് പുതിയ അഭ്യർത്ഥന വിജയിച്ചുവോ എന്ന് രേഖപ്പെടുത്തുക. അടുത്ത എഞ്ചിനീയർക്ക് വേണ്ടത് ആ രണ്ട് വസ്തുതകളാണ്, രണ്ടും സ്റ്റാറ്റസ് ഐക്കണിൽ കാണുന്നില്ല. ക്ലയന്റ് വീണ്ടും കണക്ട് ചെയ്തു എന്ന ലോഗ് വരി പ്രവർത്തിച്ച അഭ്യർത്ഥനയ്ക്ക് തുല്യമല്ല.

നയം എഴുതുക, സംഖ്യ മാത്രമല്ല

ജോഡി ഒരു വാക്യത്തിൽ ഇടുക: നിഷ്ക്രിയ ഇടവേള, ജീവനക്ഷമതയുടെ പരിധി, എന്താണ് പുനർനിർമ്മാണം ഉണ്ടാക്കുന്നത് , വീണ്ടും ശ്രമിക്കുമ്പോൾ ക്ലയന്റ് എന്ത് ചെയ്യുന്നു. ആ വാക്യമില്ലാതെ, ഓരോ ഭാവി സംഭവവും keepalive വളരെ ചെറുതാണോ വീണ്ടും കണക്ട് ചെയ്യൽ വളരെ സാവധാനമാണോ എന്ന അതേ തർക്കം വീണ്ടും തുറക്കുന്നു.

പരിധികളെക്കുറിച്ചുള്ള WireGuard കുറിപ്പുകൾ keepalive ഇടനില പെട്ടികൾക്കുള്ള ഒരു വഴിവളയമാണ്, പൊതുവായ ജീവനക്ഷമതാ രൂപകൽപ്പനയല്ല എന്നതിന്റെ ഉപയോഗപ്രദമായ ഓർമ്മപ്പെടുത്തലാണ്. അത് പരിഹരിക്കാൻ കഴിയാത്ത ഒരു പ്രശ്നത്തിന് മറുപടിയായി ആവൃത്തി കൂട്ടുന്നതിന് മുമ്പ് ആ പരിധി വായിക്കുക.