opt-verify ചേർത്താൽ OpenVPN സൈഫർ പിശക് ശരിയാകാത്തത് എന്തുകൊണ്ട്

നിങ്ങൾ opt-verify ചേർക്കാനുള്ള നിർദ്ദേശം കണ്ടെത്തി വരി ചേർക്കുന്നു, സൈഫർ പിശക് എവിടെയായിരുന്നോ അവിടെത്തന്നെ തുടരുന്നു. ഈ ഫലം പ്രതീക്ഷിതമാണ്, കാരണം ആ ഓപ്ഷൻ ഒരിക്കലും സൈഫറിനെക്കുറിച്ച് ചർച്ച നടത്തിയിട്ടില്ല. അത് ഓപ്ഷൻ സ്ഥിരതയുടെ പരിശോധനയായിരുന്നു, 2.6-ൽ കാലഹരണപ്പെട്ടതും 2.7-ൽ നീക്കം ചെയ്തതും, അതിനൊപ്പം ഇപ്പോഴും പാർസ് ചെയ്യുന്ന പ്രൊഫൈൽ അതിലൂടെ ഒന്നും നടപ്പാക്കിയിട്ടില്ല.

വരി മുമ്പ് എന്തു ചെയ്തിരുന്നു എന്ന് അറിയുന്നത് സഹായകമാണ്, അതാണ് കാണാത്ത ഭാഗം എന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ്. ഇപ്പോൾ അത് എന്തുകൊണ്ട് സഹായിക്കാനാകില്ല എന്നും ചരിത്രം വിശദീകരിക്കുന്നു.

ഓപ്ഷൻ മുമ്പ് എന്താണ് നടപ്പാക്കിയിരുന്നത്

2.6 കൈപ്പുസ്തകം opt-verify കാലഹരണപ്പെട്ടതായി അടയാളപ്പെടുത്തുകയും മുൻപത്തെ പെരുമാറ്റം വിവരിക്കുകയും ചെയ്യുന്നു: പ്രഖ്യാപിത ഓപ്ഷനുകൾ തന്റേതുമായി പൊരുത്തപ്പെടാത്ത ക്ലയന്റുകളെ സെർവർ ഒഴിവാക്കുന്നു, ഉപകരണ തരം, MTU തുടങ്ങിയവ താരതമ്യം ചെയ്യുന്നു. ആ പരിശോധന ഓപ്ഷൻ സ്ഥിരതാ പരിശോധന സജീവമായി തുടരുന്നതിനെയും ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ disable-occ-യോടെ പ്രവർത്തിക്കുന്ന സെർവറിന് അത് തുടക്കത്തിലേ ഉണ്ടായിരുന്നില്ല. താരതമ്യം എന്തിൽ നിന്നാണ് നിർമ്മിച്ചിരിക്കുന്നത് എന്ന് ശ്രദ്ധിക്കുക: മറുഭാഗത്തിന്റെ കോൺഫിഗറേഷൻ വിവരിക്കുന്ന പാഠം. ഡാറ്റാ ചാനൽ ഏത് സൈഫർ ഉപയോഗിക്കും എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.

സൈഫർ പിശക് പരിഹരിക്കാൻ ഫ്ലാഗിന് കഴിയാത്തതിന്റെ ആദ്യ കാരണം ഇതാണ്. സൈഫർ തിരഞ്ഞെടുപ്പ് data-ciphers നയവും ഇരുവശവും പിന്തുണയ്ക്കുന്നതും നിയന്ത്രിക്കുന്നു, പാഠപരമായ സ്ഥിരതാ പരിശോധന ആ പട്ടിക വിപുലീകരിക്കുകയോ ചർച്ച നടത്തുകയോ ചെയ്യുന്നില്ല. രണ്ടാമത്തെ കാരണം പരിധിയാണ്: പരിശോധന പ്രഖ്യാപിത ഓപ്ഷനുകൾ അനുയോജ്യമായി തോന്നുന്നുണ്ടോ എന്നതിനെക്കുറിച്ചാണ്, ഫലമായുണ്ടാകുന്ന പാതയുടെ ഗുണനിലവാരത്തെക്കുറിച്ചല്ല.

2.7 വരി കാണുമ്പോൾ ചെയ്യുന്നത്

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

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

പരാജയം യഥാർത്ഥത്തിൽ എവിടെയാണ്

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ആദ്യത്തെ വ്യക്തമായ പിശക് സൂക്ഷിക്കുക, കാരണം പിന്നീടുള്ള സന്ദേശങ്ങൾ സാധാരണയായി അതിന്റെ പരിണിതഫലങ്ങളാണ്. ഡാറ്റാ-ചാനൽ ചർച്ചയുടെ പരാജയം അംഗീകൃത സൈഫർ നയത്തിനും ഇരുവശവും യഥാർത്ഥത്തിൽ പ്രഖ്യാപിക്കുന്ന കഴിവുകൾക്കും ഉള്ളതാണ്. TLS പതിപ്പോ സ്യൂട്ടോ ഉള്ള പരാജയം നിയന്ത്രണ ചാനലിനുള്ളതാണ്. സർട്ടിഫിക്കറ്റ് നിരസിക്കലിന് ഐഡന്റിറ്റിയും വിശ്വാസ ശൃംഖലയും ആവശ്യമാണ്, അനുയോജ്യതാ ഫ്ലാഗല്ല.

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

വരി മാത്രമല്ല, ഉദ്ദേശ്യം മാറ്റുക

പഴയ മാനേജ്ഡ് സെർവർ യഥാർത്ഥത്തിൽ സ്ഥിരതാ പരിശോധനയെ ആശ്രയിച്ചിരുന്നെങ്കിൽ, അപ്ഗ്രേഡിന് മുമ്പ് അത് ഏത് നിയന്ത്രണമാണ് നടപ്പാക്കിയിരുന്നതെന്ന് രേഖപ്പെടുത്തുക. പുതിയ പ്രൊഫൈലിൽ അവഗണിക്കപ്പെടുന്ന ഓപ്ഷൻ നിലനിർത്തുന്നത് ആ നയം സംരക്ഷിക്കാനാകില്ല, വരികൾ ക്രമമില്ലാതെ മായ്ക്കുന്നതും സാധ്യമല്ല.

എല്ലാ സൈഫറുകളും അപ്രാപ്തമാക്കിയിരിക്കുന്നു എന്ന പഴയ നിർദ്ദേശത്തിന് എല്ലാ ചരിത്ര അൽഗോരിതവും പ്രവർത്തനക്ഷമമാക്കി മറുപടി നൽകരുത്.

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

ലക്ഷ്യം പിന്തുണയുള്ള നിയന്ത്രണവും പ്രവർത്തിക്കുന്ന പ്രാമാണീകരിച്ച പാതയുമാണ്, ഇപ്പോഴും പാർസ് ചെയ്യുന്ന പഴയ ഫ്ലാഗല്ല.