നിങ്ങളുടെ PiVPN പ്രൊഫൈൽ യഥാർത്ഥത്തിൽ ഏത് OpenVPN ഇൻസ്റ്റൻസ് ആണ് ഉപയോഗിക്കുന്നത്?

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

സഹായിയും ഡീമണും വ്യത്യസ്ത വസ്തുക്കളാണ്

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

systemd ഹോസ്റ്റിൽ ഡയറക്ടറി ലിസ്റ്റിന് പകരം സജീവ യൂണിറ്റിൽ നിന്ന് ആരംഭിക്കുക. പേര് പാക്കേജിംഗിനെ ആശ്രയിച്ചിരിക്കുന്നു: Debian, Raspberry Pi OS ഇമേജുകൾ സാധാരണയായി ഒരു ടെംപ്ലേറ്റ് ഇൻസ്റ്റൻസ് നൽകുന്നു, ഉദാഹരണത്തിന് openvpn-server@server, പഴയ ഇൻസ്റ്റാളുകൾ openvpn@server ഉപയോഗിക്കുന്നു. ഫയൽ പേരിൽ നിന്ന് ഊഹിക്കുന്നതിന് പകരം ഏതാണ് പ്രവർത്തിക്കുന്നതെന്ന് മാനേജരോട് ചോദിക്കുക.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

വായിക്കുക ExecStart= ആ ഔട്ട്പുട്ടിൽ. എക്സിക്യൂട്ടബിളും മാനേജർ യഥാർത്ഥത്തിൽ ആരംഭിക്കുന്ന ഓപ്ഷനുകളും, ഏതെങ്കിലും --config പാതയും ഇത് പേരിടുന്നു; അടുത്തുള്ളതും ഒരു കമാൻഡും റഫറൻസ് ചെയ്യാത്തതുമായ കോൺഫിഗറേഷൻ ഫയൽ പ്രവർത്തിക്കുന്ന ടണലിന്റെ ഭാഗമല്ല.

ഡീമൺ പരിഹരിച്ച കോൺഫിഗ് ശൃംഖല പിന്തുടരുക

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

ആദ്യം യഥാർത്ഥ വിളി ഡംപ് ചെയ്യുക, തുടർന്ന് ഐഡന്റിറ്റിയും എത്തിച്ചേരാനുള്ള കഴിവും തീരുമാനിക്കുന്ന നിർദ്ദേശങ്ങൾ നോക്കുക. രണ്ട് കമാൻഡുകളും വായന-മാത്രമാണ്, സജീവ സർവറിൽ സുരക്ഷിതമാണ്, എന്നിരുന്നാലും രണ്ടാമത്തേത് പൊതു ടിക്കറ്റിൽ നിങ്ങൾ ആഗ്രഹിക്കാത്ത പാതകൾ പ്രിന്റ് ചെയ്യുന്നു.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

ഹോം ഡയറക്ടറിയിലെ .ovpn ഫയൽ ഒരു ക്ലയന്റ് ആർട്ടിഫാക്ട് ആണ്. സർവർ ഡീമൺ അത് ഒരിക്കലും വായിക്കുന്നില്ല, അതിനാൽ സർവർ വശത്തെ ഹാൻഡ്ഷേക്ക് പരാജയം പരിഹരിക്കാൻ ആ ഫയൽ എഡിറ്റ് ചെയ്യുന്നത് ഒന്നും നേടുന്നില്ല.

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

ലോഗ് ഓർക്കുന്ന പിശകിനോടല്ല, പ്രക്രിയയോട് ചേർക്കുക

രണ്ട് ലോഗ് ലക്ഷ്യങ്ങൾ സാധാരണമാണ്, അവയിൽ ഒന്ന് മാത്രമാണ് journal. log-append സെറ്റ് ചെയ്താൽ ഡീമൺ ആ ഫയലിൽ എഴുതുന്നു, journal സ്റ്റാർട്ടപ്പ് വരികൾക്കപ്പുറം കുറച്ചേ സൂക്ഷിക്കുന്നു. അതില്ലാതെ journalctl ഇവന്റുകളുടെ ഉറവിടമാണ്.

journalctl -u openvpn-server@server -n 80 --no-pager

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

പഴയ ലോഗ് എൻട്രി അഞ്ച് മിനിറ്റ് മുമ്പ് ഡൗൺലോഡ് ചെയ്ത പ്രൊഫൈലിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. ക്ലയന്റ് ഫയൽ വീണ്ടും ജനറേറ്റ് ചെയ്യുക, ഒരിക്കൽ കണക്ട് ചെയ്യുക, ആ ശ്രമത്തിൽ പ്രത്യക്ഷപ്പെട്ട വരികൾ മാത്രം വായിക്കുക.

അവസാന പൊതു പരാജയത്തിന് പകരം ആദ്യത്തെ നിർദ്ദിഷ്ട പരാജയം രേഖപ്പെടുത്തുക. ബൈൻഡ് പിശക്, മറുപടിയില്ലാത്ത ബാഹ്യ കൈമാറ്റം, സർട്ടിഫിക്കറ്റ് നിരസനം, അക്കൗണ്ട് നിരസനം എന്നിവ ഓരോന്നും വേറെ പാളിയിലേക്ക് അയക്കുന്നു, അവസാനത്തെ ടൈംഔട്ട് പലപ്പോഴും മുകളിലെ ഉപയോഗപ്രദമായ ഇവന്റ് മറയ്ക്കുന്നു.

ടണൽ വീണ്ടും നിർമ്മിക്കുന്നത് രോഗനിർണയ ഘട്ടമല്ല

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

അതുതന്നെ tls-auth അല്ലെങ്കിൽ tls-crypt പ്രവർത്തനരഹിതമാക്കുന്നതിനും, verify-x509-name അയച്ചുവിടുന്നതിനും, അല്ലെങ്കിൽ പച്ച നിലയ്ക്കായി രണ്ടാം ഘടകം ഉപേക്ഷിക്കുന്നതിനും ബാധകമാണ്. സ്ഥിരീകരണം നീക്കിയതുകൊണ്ട് കണക്ട് ചെയ്യുന്ന ടണൽ മറ്റൊരു സിസ്റ്റമാണ്, നന്നാക്കിയതല്ല.

ലോഗ് പേരിട്ട പാളിയിൽ ഒരു പരിമിത മാറ്റം വരുത്തുക, അതേ യൂണിറ്റ് റീസ്റ്റാർട്ട് ചെയ്യുക, ആ ഒറ്റ കണക്ഷൻ ശ്രമം ആവർത്തിക്കുക. അത് താരതമ്യം സത്യസന്ധമായി നിലനിർത്തുന്നു, തിരികെയെടുക്കാവുന്ന ഒരു മാറ്റം അവശേഷിപ്പിക്കുന്നു.

അടുത്ത വ്യക്തിക്ക് എന്ത് കൈമാറണം

നാല് വസ്തുതകൾ ഇപ്പോഴും കൈവശമുള്ളപ്പോൾ എഴുതുക: OpenVPN പതിപ്പ് openvpn --version ഔട്ട്പുട്ടിൽ നിന്ന്, സജീവ യൂണിറ്റ്, ഇൻക്ലൂഡുകളോടുകൂടിയ കോൺഫിഗ് ശൃംഖല, ഒരു ശ്രമം ഉൾക്കൊള്ളുന്ന ലോഗ് വിൻഡോ. ആ നാലും അവ്യക്തമായ പരാതിയെ പുനർനിർമ്മിക്കാവുന്ന കേസാക്കി മാറ്റുന്നു.

പങ്കിടുന്നതിന് മുമ്പ് സെൻസിറ്റീവ് ഡാറ്റ മായ്ക്കുക. സ്വകാര്യ കീകൾ, auth-user-pass ഫയലുകൾ, സ്റ്റാറ്റിക് കീ മെറ്റീരിയൽ, പൂർണ്ണ ക്ലയന്റ് ബണ്ടിലുകൾ എന്നിവ ടിക്കറ്റിൽ ഉണ്ടാകരുത്; ഓപ്ഷൻ പേരുകളും ശൃംഖലയുടെ ആകൃതിയും സാധാരണയായി രണ്ടാം കണ്ണിന് മതിയാകും.

ശൃംഖല അഖണ്ഡവും ലോഗ് ഇപ്പോഴും നെറ്റ്വർക്കിലേക്ക് ചൂണ്ടുന്നതുമാണെങ്കിൽ, അടുത്ത ഘട്ടം ക്ലയന്റും സർവറും തമ്മിലുള്ള പാതയാണ്, മറ്റൊരു ഇൻസ്റ്റാളേഷനല്ല. അതാണ് സഹായിക്ക് ഒരിക്കലും ഉണ്ടായിരിക്കാത്ത കഥയുടെ ഭാഗം.