ലോഗിൽ P_CONTROL_HARD_RESET_CLIENT_V2: ഇത് പിശകാണോ?

ഈ വരി ഓരോ കുറഞ്ഞ സെക്കൻഡിലും ആവർത്തിക്കുകയും എല്ലാറ്റിന്റെയും കാരണമായി തോന്നുകയും ചെയ്യുന്നു: control hard reset എന്ന പാക്കറ്റ്, എങ്ങും എത്താത്ത ഒരു ക്ലയന്റിൽ നിന്ന് വരുന്നു. ഇത് പിശകല്ല. ഇത് പുതിയ സെഷന്റെ ആദ്യ സന്ദേശമാണ്, ആവർത്തനം മറ്റെന്തോ പിന്നീട് പരാജയപ്പെടുന്നതിന്റെ ലക്ഷണമാണ്. ലേബൽ പറയുന്നതും കണക്ഷൻ പിന്നീട് ചെയ്തതും വേർതിരിക്കുന്നതാണ് മുഴുവൻ രോഗനിർണയം.

ഓപ്‌കോഡ് പ്രോട്ടോക്കോളിലെ ഒരു സ്ഥാനത്തെ സൂചിപ്പിക്കുന്നു

OpenVPN ഒരു സോക്കറ്റിൽ നിരവധി തരം പാക്കറ്റുകൾ മൾട്ടിപ്ലക്സ് ചെയ്യുന്നു, ഓപ്‌കോഡ് സ്വീകർത്താവിനോട് ഏത് തരം പിടിച്ചിരിക്കുന്നു എന്ന് പറയുന്നു. hard-reset പാക്കറ്റുകൾ സെഷൻ തുറക്കുന്നു, നിയന്ത്രണ പാക്കറ്റുകൾ ഹാൻഡ്ഷേക്ക് വസ്തുക്കൾ വഹിക്കുന്നു, സ്വീകരണങ്ങൾ സ്വീകാരം സ്ഥിരീകരിക്കുന്നു, ഡാറ്റ പാക്കറ്റുകൾ ടണലിന്റെ ഭാരം വഹിക്കുന്നു. ആദ്യ ബൈറ്റ് വായിക്കുന്നത് ആ കൈമാറ്റത്തിൽ പാക്കറ്റ് എവിടെ വരുന്നു എന്ന് കാണിക്കുന്നു, കൂടാതെ സ്രോതസ്സ് കോഡിലെ പാക്കറ്റ് നിർവചനങ്ങൾ ഓരോ കുടുംബത്തെയും വ്യക്തമായി പേരിടുന്നു.

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

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

ആ നിമിഷത്തിൽ ക്ലയന്റ് യഥാർത്ഥത്തിൽ ചെയ്യുന്നത്

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

ഉപയോക്താവിന് കാണാവുന്നത് ഇതുവരെ സംഭവിച്ചിട്ടില്ല. ഒരു സർട്ടിഫിക്കറ്റും സാധൂകരിച്ചിട്ടില്ല, ഒരു ഉപയോക്തൃനാമവും നൽകിയിട്ടില്ല, ഒരു ടണൽ വിലാസവും അനുവദിച്ചിട്ടില്ല. റീസെറ്റ് ഹാൻഡ്ഷേക്കിന്റെ പ്രവേശകമാണ്, അതിനാൽ ഈ നിമിഷത്തിൽ കണക്ഷനെക്കുറിച്ചുള്ള ഏത് വിലയിരുത്തലും അകാലമാണ്.

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

റീസെറ്റിനു ശേഷം യഥാർത്ഥ പരാജയം എവിടെ ഒളിക്കുന്നു

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

ഓരോ ലോഗും വെവ്വേറെ വായിക്കുന്നതിനുപകരം ഒരു ശ്രമം സമയമുദ്ര അനുസരിച്ച് ചേർക്കുക, കാരണം അതേ പരാജയം ഇരുവശത്തും വ്യത്യസ്ത വാക്കുകളിലും വ്യത്യസ്ത തീവ്രതയിലും പ്രത്യക്ഷപ്പെടുന്നു. കീഴടങ്ങുന്ന സമഭാഗി സാധാരണയായി കാരണം പറയുന്നു.

ഒരു വശവും നിരസിക്കൽ റിപ്പോർട്ട് ചെയ്യുന്നില്ലെങ്കിലും കൈമാറ്റം നിലയ്ക്കുന്നുവെങ്കിൽ, പരിധി വിശ്വാസമല്ല, പ്രാപ്യതയാണ്. മടക്കദിശ ഉപേക്ഷിക്കുന്ന ഫയർവാൾ, മാപ്പിംഗ് കാലഹരണപ്പെടുന്ന നെറ്റ്‌വർക്ക് വിലാസ അനുവാദ ഉപകരണം, അല്ലെങ്കിൽ വലിയ ഹാൻഡ്ഷേക്ക് പാക്കറ്റുകളെ കൊല്ലുന്ന MTU പ്രശ്നം — എല്ലാം പ്രാമാണീകരണ പിശകില്ലാതെ നിലച്ച കൈമാറ്റം സൃഷ്ടിക്കുന്നു.

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

ആ തിരയൽ സ്വയം രോഗനിർണയമല്ല, പക്ഷേ ഒരു ചുവടിൽ നിങ്ങളെ പ്രോട്ടോക്കോൾ പദാവലിയിൽ നിന്ന് യഥാർത്ഥ പരാജയ വിഭാഗത്തിലേക്ക് കൊണ്ടുപോകുന്നു.

സ്ഥിരീകരണം ഓഫാക്കുന്നത് എന്തുകൊണ്ട് തെറ്റായ പ്രതികരണം

റീസെറ്റ് വീണ്ടും പ്രത്യക്ഷപ്പെടുമ്പോൾ, ഏറ്റവും വേഗമേറിയതായി തോന്നുന്ന പരിഹാരം സർട്ടിഫിക്കറ്റ് സ്ഥിരീകരണം ഓഫാക്കുകയോ എന്തെങ്കിലും ബന്ധിപ്പിക്കാൻ നിയന്ത്രണ-ചാനൽ സംരക്ഷണം ഉപേക്ഷിക്കുകയോ ചെയ്യുകയാണ്. അത് രോഗനിർണയം ചെയ്യാവുന്ന പരാജയത്തെ ചെയ്യാനാവാത്ത ഒന്നുമായി മാറ്റുന്നു, നിരസിക്കാൻ നിർമ്മിച്ച സമഭാഗികളെ സ്വീകരിക്കാൻ വിന്യാസത്തെ വിടുന്നു.

പകരം യഥാർത്ഥത്തിൽ പരാജയപ്പെട്ട പരിധി മാറ്റുക. വിശ്വാസ പ്രശ്നം സർട്ടിഫിക്കറ്റ് അതോറിറ്റിക്കും അതിനെ പരാമർശിക്കുന്ന പ്രൊഫൈലിനുമാണ്. സമയ പ്രശ്നം ക്ലോക്കിനാണ്. ക്രെഡൻഷ്യൽ പ്രശ്നം അവ നിരസിച്ച പ്രാമാണീകരണ ബാക്കെൻഡിനാണ്, പ്രാപ്യമല്ലാത്ത സമഭാഗി രണ്ട് ഹോസ്റ്റുകൾക്കിടയിലെ പാതയ്ക്കാണ്.

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