OpenVPN ആദ്യ വരി നിരസിക്കുന്നുണ്ടോ? ഫയൽ ഒരുപക്ഷേ UTF-16 ആണ്

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

മിഥ്യ: എഡിറ്റർ നിങ്ങൾക്ക് ഫയൽ കാണിച്ചുതരുന്നു

ടെക്സ്റ്റ് എഡിറ്റർ കണ്ടെത്തുന്നതോ ഊഹിക്കുന്നതോ ആയ എൻകോഡിംഗ് ഉപയോഗിച്ച് ബൈറ്റുകളെ അക്ഷരങ്ങളാക്കി മാറ്റുന്നു. UTF-16 എന്ന് ഊഹിക്കുമ്പോൾ ഫയൽ സ്ക്രീനിൽ തികഞ്ഞതായി തോന്നുന്നു, എന്നാൽ താഴെയുള്ള ബൈറ്റുകൾ ജോടികളാണ്, ഓരോ ലാറ്റിൻ അക്ഷരത്തിനും ശേഷം പൂജ്യം ബൈറ്റ് വരുന്നു. OpenVPN ആ ബൈറ്റുകളെ അക്ഷരങ്ങളായി വായിക്കുന്നു, വിശകലനം ചെയ്യാൻ ശ്രമിക്കുന്ന ആദ്യ നിർദ്ദേശത്തിൽ വൈരുദ്ധ്യം പ്രത്യക്ഷപ്പെടുന്നു.

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

പരാജയത്തിന്റെ കൃത്യമായ രൂപം തിരിച്ചറിയേണ്ടതാണ്, കാരണം അത് ഒരു പ്രത്യേക രീതിയിൽ രോഗനിർണ്ണയാത്മകമാണ്. മറ്റ് യന്ത്രങ്ങളിൽ മറ്റൊരു രീതിയിൽ പ്രവർത്തിച്ച പ്രൊഫൈലിൽ ഫയലിന്റെ തുടക്കത്തിൽ തന്നെ ഒരു ടോക്കൺ ഉണ്ടെങ്കിൽ അത് പദാവലിയുടെ ചോദ്യമല്ല, ബൈറ്റ് ക്രമത്തിന്റെ ചോദ്യമാണ്.

ആദ്യ ബൈറ്റുകൾ യഥാർത്ഥത്തിൽ എന്ത് പറയുന്നു

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

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

നിങ്ങൾ തിരയുന്ന മാതൃക ആദ്യത്തെ രണ്ട് ബൈറ്റുകളും തുടർന്ന് ഓരോ രണ്ടാമത്തെ ബൈറ്റും പൂജ്യമായ വാചകവുമാണ്. FF FE UTF-16 ലിറ്റിൽ-എൻഡിയൻ സൂചിപ്പിക്കുന്നു, FE FF ബിഗ്-എൻഡിയൻ സൂചിപ്പിക്കുന്നു, EF BB BF ബൈറ്റ് ക്രമ അടയാളത്തോടുകൂടിയ UTF-8 സൂചിപ്പിക്കുന്നു. അടയാളമില്ലാത്ത സാധാരണ UTF-8 ഫയൽ ആദ്യ അക്ഷരത്തിന്റെ ബൈറ്റിൽ നിന്ന് നേരിട്ട് ആരംഭിക്കുന്നു.

അക്ഷരങ്ങൾക്കിടയിലെ പൂജ്യം ബൈറ്റുകളാണ് പ്രധാന സൂചന. UTF-16 ലിറ്റിൽ-എൻഡിയനിൽ client എന്ന വാക്ക് ആറിന് പകരം പന്ത്രണ്ട് ബൈറ്റ് എടുക്കുന്നു, കാരണം ഓരോ ASCII അക്ഷരത്തിനും ശേഷം പൂജ്യം വരുന്നു. ആ ഘടന എഡിറ്ററിന്റെ സ്ക്രീനിന് കാണിക്കാനാവില്ല, രണ്ട് ബൈറ്റ് മായ്ക്കുന്നതുകൊണ്ട് അത് ഒഴിവാക്കാനും കഴിയില്ല.

ഇവിടെ ഒരു പ്രധാന സൂക്ഷ്മതയുണ്ട്: 2.6 കോൺഫിഗറേഷൻ റീഡർ കാണിക്കുന്നതുപോലെ OpenVPN-ന്റെ കോൺഫിഗറേഷൻ റീഡർ ഫയലിന്റെ തുടക്കത്തിലെ UTF-8 ബൈറ്റ് ക്രമ അടയാളം യഥാർത്ഥത്തിൽ ഒഴിവാക്കുന്നു. ആ സഹിഷ്ണുത ആ അടയാളത്തിന് മാത്രമുള്ളതാണ്, അക്ഷരങ്ങൾ പൂജ്യങ്ങൾ കൊണ്ട് നിറച്ച UTF-16 ഫയലിന് അത് ഒന്നും ചെയ്യുന്നില്ല. രണ്ട് അടയാളങ്ങളെയും ഒരേ പ്രശ്നമായി കാണുന്നതാണ് മിഥ്യയുടെ രണ്ടാം പകുതി.

തിരുത്തിയ എൻകോഡിംഗ് തിരുത്താത്തത്

എന്തെങ്കിലും ചെയ്യുന്നതിന് മുമ്പ് ഓപ്പറേറ്ററുടെ ഒറിജിനലിന്റെ തീണ്ടാത്ത പകർപ്പ് സൂക്ഷിക്കുക, വേറെ ഫയലിൽ പ്രവർത്തിക്കുക. പ്രൊഫൈലിൽ സ്വകാര്യ കീ അല്ലെങ്കിൽ അക്കൗണ്ട് വിവരങ്ങൾ ഉണ്ടാകാം, അതിനാൽ പകർപ്പ് നിങ്ങളുടെ പിന്നോട്ടുള്ള വഴിയും റഫറൻസും ഒരുപോലെയാണ്.

തുടർന്ന് യഥാർത്ഥ എൻകോഡിംഗ് പരിവർത്തനം നടത്തുക, ഒന്നുകിൽ എഡിറ്ററിന്റെ വ്യക്തമായ എൻകോഡിംഗ് മെനു വഴി, അല്ലെങ്കിൽ ഇൻപുട്ടും ഔട്ട്പുട്ട് എൻകോഡിംഗും വ്യക്തമാക്കുന്ന ഒരു കൺവെർട്ടർ ഉപയോഗിച്ച്:

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

കമാൻഡിന്റെ എക്സിറ്റ് സ്റ്റാറ്റസ് വിശ്വസിക്കുന്നതിന് പകരം ഫലം പരിശോധിക്കുക. പരിവർത്തനം ഓരോ നിർദ്ദേശവും സംരക്ഷിക്കണം, അതിന്റെ മാർക്കറുകൾക്കുള്ളിൽ ഏതെങ്കിലും ഇൻലൈൻ സർട്ടിഫിക്കറ്റ് അല്ലെങ്കിൽ കീ ബ്ലോക്ക് ബൈറ്റ് അനുസരിച്ച് സംരക്ഷിക്കണം. PEM ഡാറ്റ വീണ്ടും പൊതിയുന്നതോ, ബ്ലോക്കിനുള്ളിൽ ലൈൻ അവസാനങ്ങൾ മാറ്റുന്നതോ, പരിവർത്തന സമയത്ത് പ്രൊഫൈൽ വീണ്ടും ഫോർമാറ്റ് ചെയ്യുന്നതോ പഴയ പ്രശ്നം പരിഹരിക്കുമ്പോൾ പുതിയ പ്രശ്നം സൃഷ്ടിക്കുന്നു.

ക്ലൈന്റിനെയോ സേവനത്തെയോ പരിവർത്തനം ചെയ്ത ഫയലിലേക്ക് ചൂണ്ടിക്കാണിച്ച് അത് റിപ്പോർട്ട് ചെയ്യുന്ന ആദ്യ പിശക് നോക്കുക. കലങ്ങിയ ടോക്കൺ പോയെങ്കിൽ എൻകോഡിംഗ് ജോലി കഴിഞ്ഞു, അതിന് ശേഷം പരാജയപ്പെടുന്നതെല്ലാം വേറെ ചോദ്യമാണ്.

തിരുത്തിയ എൻകോഡിംഗ് തിരുത്താത്തവ

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

ആ പിന്നീടുള്ള പിശകുകൾ സ്വന്തം അന്വേഷണത്തിന് അർഹമാണ്: കൃത്യമായ അക്ഷരവിന്യാസം, ആർഗ്യുമെന്റിന്റെ വാക്യഘടന, അത് സ്വീകരിക്കുന്ന പതിപ്പ്. വിജയകരമായ വിശകലനത്തെ വിജയകരമായ പ്രൊഫൈൽ ആയി കാണരുത്.

ഇതിൽ ഏർപ്പെട്ടിരിക്കുമ്പോൾ അന്വേഷണം പ്രാദേശികമായി നിർത്തുക. പൊതു ഓൺലൈൻ കൺവെർട്ടറുകളും പേസ്റ്റ് ചെയ്ത hex ഡംപുകളും സ്വകാര്യ കീ ഉണ്ടായേക്കാവുന്ന ഫയലിന് മോശം സ്ഥലമാണ്, കാരണം എൻകോഡിംഗ് പ്രശ്നം പരിഹരിക്കാൻ എളുപ്പമാണ്, ചോർന്ന കീ അല്ല.