OpenVPN 3 Linux: പിന്നോട്ട് പോകുന്നതിന് മുമ്പ് D-Bus പിശക് വായിക്കുക
അഞ്ച് സേവനങ്ങൾ, ഒരു ഫ്രണ്ട്എൻഡ്. D-Bus പിശക് നിരസിച്ച ഘടകത്തിന് ആരോപിക്കുക, സെഷൻ ഉണ്ടോ എന്ന് പരിശോധിക്കുക, പിന്നെ ആ അതിർത്തിയിൽ തിരുത്തുക.
OpenVPN 3 Linux-ലെ പരാജയങ്ങൾ അപരിചിതമായ പേരോടുകൂടിയ D-Bus രീതി പിശകായി വരുന്നു, പ്രലോഭനം പാക്കേജ് താഴ്ത്തി പ്രതീക്ഷിക്കുക എന്നതാണ്. ക്ലയന്റ് ഒരു പ്രോഗ്രാം അല്ല: കമാൻഡ് ലൈൻ ഫ്രണ്ട്എൻഡ് ബസ് വഴി പ്രൊഫൈലുകൾ, സെഷനുകൾ, VPN എഞ്ചിൻ, പ്രത്യേക അനുമതിയുള്ള നെറ്റ്വർക്ക് മാറ്റങ്ങൾ എന്നിവയുടെ ഉടമകളായ സേവനങ്ങളോട് സംസാരിക്കുന്നു. ഈ അഞ്ചിൽ ഏതാണ് പരാജയപ്പെട്ട കോളിന്റെ ഉടമ എന്ന് തീരുമാനിക്കുന്നതാണ് രോഗനിർണയത്തിന്റെ വലിയ ഭാഗം, അത് പിന്നോട്ട് പോകുന്നതിന് പകരം ഒരു കമാൻഡിന്റെ ചെലവ് മാത്രമാണ്. തുടർന്ന് വരുന്നത് ആ തീരുമാനമാണ്, പരാജയങ്ങൾ സാധാരണ പ്രത്യക്ഷപ്പെടുന്ന ക്രമത്തിൽ.
ഒരു കമാൻഡിന് പിന്നിൽ അഞ്ച് ഉടമകൾ
അഞ്ച് പ്രക്രിയകൾ പ്രധാനമാണ്, ഓരോന്നിനും സ്വന്തം ബസ് പേരുണ്ട്: നിങ്ങളുടെ കമാൻഡ് സ്വീകരിക്കുന്ന ഫ്രണ്ട്എൻഡ്, പ്രൊഫൈലുകളും അവയുടെ പ്രവേശന നയവും സൂക്ഷിക്കുന്ന കോൺഫിഗറേഷൻ മാനേജർ, സെഷന്റെ ആയുസ്സ് കൈവശമുള്ള സെഷൻ മാനേജർ, OpenVPN 3 Core Engine വഴി കണക്ഷൻ ഓടിക്കുന്ന ബാക്കെൻഡ്, ഇന്റർഫേസും റൂട്ടുകളും DNS ക്രമീകരണങ്ങളും ഇൻസ്റ്റാൾ ചെയ്യുന്ന നെറ്റ്വർക്ക് കോൺഫിഗറേഷൻ സേവനം. അതിനാൽ കോൺഫിഗറേഷൻ ഒബ്ജക്റ്റിനെ പേരിടുന്ന പിശക് ബാക്കെൻഡ് പിശകല്ല, തുടങ്ങാത്ത ബാക്കെൻഡ് പ്രാമാണീകരണ പരാജയവുമല്ല. സന്ദേശത്തെ ആ വരികളിൽ ഒന്നിൽ ഉൾപ്പെടുത്തുന്നത് എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് സംഭവിക്കണം, കാരണം ഓരോ അടുത്ത ഘട്ടവും ഏത് വരിയാണ് ശരി എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. വരി ഊഹിക്കുന്നതാണ് ചെറിയ തിരുത്ത് പാക്കേജുകളുമായി പകൽ മുഴുവൻ ജോലിയാകുന്ന വഴി.
മറ്റെന്തെങ്കിലും ചോദിക്കുന്നതിന് മുമ്പ് സിസ്റ്റം ബസിനോട് ഏതൊക്കെ സേവനങ്ങൾ ഉണ്ടെന്ന് ചോദിക്കുക, പിന്നെ ഇൻസ്റ്റാൾ ചെയ്ത ഭാഗങ്ങൾ ഒരു പതിപ്പിൽ യോജിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. OpenVPN 3 Linux ആ സേവനങ്ങളെ സിസ്റ്റം യൂണിറ്റുകളായി രജിസ്റ്റർ ചെയ്യുന്നു, അതിനാൽ ചോദിക്കേണ്ട ബസ് സിസ്റ്റം ബസാണ്, പതിപ്പ് ചോദ്യത്തിന് ഭരണ അധികാരം വേണം, --user ഉപയോഗിച്ച് ഉണ്ടാക്കിയ ലിസ്റ്റ് നിങ്ങളുടെ ലോഗിൻ സെഷൻ വായിക്കുന്നു, അവിടെ യൂണിറ്റുകൾ ഒരിക്കലും പ്രത്യക്ഷപ്പെടുന്നില്ല. സേവനങ്ങൾ ആവശ്യത്തിനനുസരിച്ച് സജീവമാകുന്നു, ചിലത് നിഷ്ക്രിയമാകുമ്പോൾ പുറത്തുപോകുന്നു, അതിനാൽ നിങ്ങളുടെ ആദ്യ അഭ്യർത്ഥനയ്ക്ക് മുമ്പ് ഇല്ലാത്ത സേവനത്തോട് ഇതുവരെ ഒന്നിനെപ്പറ്റിയും ചോദിച്ചിട്ടില്ല. താഴെയുള്ള മൂന്ന് കമാൻഡുകൾ VPN സെഷൻ തുറക്കാതെ സാന്നിധ്യം, പതിപ്പ്, യൂണിറ്റ് അവസ്ഥ എന്നിവയ്ക്ക് ഉത്തരം നൽകുന്നു.
sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'ഓരോ ലിസ്റ്റും യഥാർത്ഥത്തിൽ എന്ത് തെളിയിക്കുന്നു
ക്ലയന്റിന്റെ സ്വന്തം കാഴ്ചകളാണ് ലഭ്യമായ ഏറ്റവും വിലകുറഞ്ഞ തെളിവ്, അവയിൽ ഓരോന്നും തോന്നുന്നതിനേക്കാൾ കുറവ് തെളിയിക്കുന്നു. കോൺഫിഗറേഷൻ ലിസ്റ്റിലെ പ്രൊഫൈൽ ഒരു പ്രൊഫൈൽ ഇംപോർട്ട് ചെയ്തുവെന്ന് കാണിക്കുന്നു, ആർക്കെങ്കിലും അതുമായി ബന്ധിപ്പിക്കാമോ എന്നതിനെപ്പറ്റി ഒന്നും പറയുന്നില്ല. സെഷൻ ലിസ്റ്റിലെ സെഷൻ സെഷൻ ഒബ്ജക്റ്റ് ഉണ്ടെന്ന് കാണിക്കുന്നു, വിദൂര പ്രാമാണീകരണം തീർന്നുവോ എന്നതിനെപ്പറ്റി ഒന്നും പറയുന്നില്ല.
openvpn3 configs-list
openvpn3 sessions-listആ ഔട്ട്പുട്ടുകളിലെ ഒബ്ജക്റ്റ് പാതകൾ ബസിൽ നിയന്ത്രിക്കപ്പെടുന്ന ഒബ്ജക്റ്റുകളെ സൂചിപ്പിക്കുന്നു, ഫയലുകളെയല്ല, അതിനാൽ അവ എഡിറ്റ് ചെയ്യാൻ കഴിയില്ല, മുമ്പ് രേഖപ്പെടുത്തിയ പാത ആ സെഷൻ വിച്ഛേദിക്കുന്ന നിമിഷത്തിൽ പഴയതാകുന്നു. നിങ്ങളുടെ കുറിപ്പുകളിൽ നിന്ന് ഒന്ന് വീണ്ടും ഉപയോഗിക്കുന്നത് VPN-മായി യാതൊരു ബന്ധവുമില്ലാത്ത "no such object" പിശകുകൾ സൃഷ്ടിക്കുന്നു. താഴെയുള്ള ഘട്ട പട്ടിക കണക്ഷന്റെ ഓരോ ഘട്ടവും എന്ത് സ്ഥാപിക്കുന്നു, എന്ത് തുറന്നിടുന്നു എന്ന് വേർതിരിക്കുന്നു, പിന്നോട്ട് പോകാനുള്ള തീരുമാനം അതേ വ്യത്യാസത്തിലാണ് നിൽക്കുന്നത്. നിങ്ങളുടെ തെളിവിന് യോജിക്കുന്ന വരി വായിക്കുക, പിന്നെ പിശകിന്റെ പാഠം വീണ്ടും വായിക്കുക.
| Stage | What exists | What proves it | What it does not prove |
|---|---|---|---|
| Profile imported | A configuration object held by the configuration manager | The profile is listed by the client | That the profile owner permits a connection |
| Session requested | A session object held by the session manager | The session appears in the session list | That the remote side accepted the credentials |
| Connect dispatched | An asynchronous attempt on the VPN backend | Status changes arrive for that session | That an interface was configured |
| Tunnel configured | An interface, routes and DNS settings | The network service reports success and routes appear | That traffic reaches the peer |
കണക്ഷൻ കോൾ തുരങ്കം നിലവിൽ വരുന്നതിന് മുമ്പ് മടങ്ങുന്നു
കണക്ഷൻ കോൾ നിങ്ങൾക്ക് നിരീക്ഷിക്കാൻ ഒരു സെഷൻ തരുന്നു, പിന്നെ മടങ്ങുന്നു, അതുകൊണ്ടാണ് പ്രത്യക്ഷത്തിൽ വിജയകരമായ കോളിന് ശേഷം നിശബ്ദത വരുന്നത് സാധാരണ ഇടക്കാല അവസ്ഥയാണ്, വൈരുദ്ധ്യമല്ല. ഫ്രണ്ട്എൻഡ് ഇപ്പോഴും അവസ്ഥാ മാറ്റങ്ങൾ പിന്തുടരണം, ഓരോ ഇടപെടൽ അഭ്യർത്ഥനയ്ക്കും ഉത്തരം നൽകണം. ഒരു സാക്ഷ്യപത്രം ആവശ്യമായി ഉത്തരം ലഭിക്കാത്ത പ്രൊഫൈൽ കുടുങ്ങിയ ബാക്കെൻഡിനെപ്പോലെ കൃത്യമായി കാണുന്ന അവസ്ഥയിൽ കാത്തിരിക്കുന്നു. ആ കാത്തിരിപ്പ് അവസ്ഥ തിരിച്ചറിയപ്പെടണം, കാരണം അത് ആളുകളെ തെറ്റായ ഘടകത്തിലേക്ക് അയക്കുന്നു.
ഒരു ശ്രമം നടക്കുമ്പോൾ, ആ പ്രൊഫൈലിനുള്ള സെഷൻ ലിസ്റ്റും ഫ്രണ്ട്എൻഡിന്റെ സ്വന്തം ലോഗും നിരീക്ഷിക്കുക. തന്റെ പ്രാരംഭ അവസ്ഥ ഒരിക്കലും വിടാത്ത സെഷൻ നിന്ന ഘടകത്തെ പേരിടുന്നു, ലോഗ് സാധാരണ ആദ്യ വരികളിൽ തന്നെ അതിനെ പേരിടുന്നു. പ്രൊഫൈൽ പേര് കൈയിൽ സൂക്ഷിക്കുക, കാരണം ലോഗ് കമാൻഡ് സെഷൻ പാതയല്ല, പ്രൊഫൈൽ എടുക്കുന്നു, ഇത് പാത വീണ്ടും ഉപയോഗിക്കുന്നതിന് പകരം ലിസ്റ്റ് വീണ്ടും വായിക്കാൻ മറ്റൊരു കാരണമാണ്.
openvpn3 sessions-list
openvpn3 log --config <profile> --level 6സെഷൻ തുറക്കാതെ ഒരു ഘടകത്തിന്റെ ലോഗ് വായിക്കൽ
ഫ്രണ്ട്എൻഡ് ഉപയോഗപ്രദമായ ഒന്നും അറിയിക്കാത്തപ്പോൾ, പുതിയ കണക്ഷൻ തുടങ്ങുന്നതിന് പകരം പരാജയം ലോഗ് ചെയ്ത ഘടകത്തിലേക്ക് പോകുക. കോൺഫിഗർ ചെയ്ത systemd-journald ലോഗറിനൊപ്പം, ഭരണാധികാരിയുടെ പരിമിതമായ ജേണൽ കാഴ്ച ഒരു ഘടകത്തിന്റെ സംഭവങ്ങൾ വായിക്കുന്നു, ബസ് നയത്തെ സ്പർശിക്കാതെ സെഷനും തുറക്കാതെ, ഇത് പ്രധാനമാണ് കാരണം അളക്കപ്പെടുന്ന സിസ്റ്റത്തെത്തന്നെ മാറ്റുന്ന രോഗനിർണയം വളരെ കുറച്ചേ തെളിയിക്കുന്നുള്ളൂ. യൂണിറ്റ് അനുസരിച്ച് ഫിൽട്ടർ ചെയ്യുക, syslog ടാഗ് അനുസരിച്ചല്ല: വ്യക്തിഗത സേവന യൂണിറ്റുകൾ പൊതുവായ ഐഡന്റിഫയറിന് ഉറപ്പ് നൽകുന്നില്ല, അതിനാൽ ടാഗ് അന്വേഷണം ശൂന്യമായ പേജ് തിരികെ നൽകിയേക്കാം, അതേസമയം യൂണിറ്റ് തന്നെ പരാജയം രേഖപ്പെടുത്തിയിരിക്കും.
ആരോടെങ്കിലും സഹായം ചോദിക്കുന്നതിന് മുമ്പ് നാല് ഫീൽഡുകൾ രേഖപ്പെടുത്തുക: പിശകിന്റെ മുഴുവൻ പേര്, ബന്ധപ്പെട്ട സേവനവും ഒബ്ജക്റ്റും, സമയ മുദ്ര, ഇൻസ്റ്റാൾ ചെയ്ത പാക്കേജുകളുടെ പതിപ്പുകൾ. ഇവയാണ് പരിപാലകന് ആവശ്യം, ഇവയിൽ ഒന്നിനും പ്രൊഫൈലോ സാക്ഷ്യപത്രമോ ടിക്കറ്റിൽ ഒട്ടിക്കേണ്ടതില്ല. പിശക് നിശബ്ദമാക്കാൻ ബസ് പ്രവേശന നയം വിശാലമാക്കുന്നത് രോഗനിർണയമല്ല, അത് നിങ്ങൾക്കുവേണ്ടി ഘടകത്തെ പേരിട്ട അതിർത്തി മായ്ക്കുന്നു. പ്രൊഫൈലുകളുടെ സ്വകാര്യ ഉള്ളടക്കം പങ്കിട്ട റിപ്പോർട്ടുകൾക്ക് പുറത്ത് നിൽക്കുന്നു, സാക്ഷ്യപത്രങ്ങൾ പുറത്ത് നിൽക്കുന്ന അതേ കാരണത്താൽ.
journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>നിരസിച്ച അതിർത്തിയുടെ തിരുത്ത്
ഭൂപടത്തിലെ ഓരോ വരിക്കും അതിന്റേതായ തിരുത്തുണ്ട്, വരികൾ പരസ്പരം മാറ്റിസ്ഥാപിക്കുന്നില്ല. പ്രൊഫൈലിൽ നിരസിച്ച പ്രവർത്തനം നയത്തിന്റെയും ഉടമസ്ഥതയുടെയും ചോദ്യമാണ്, അതേസമയം സജീവമാകാത്ത ബാക്കെൻഡ് സേവനങ്ങളുടെയും പാക്കേജിംഗിന്റെയും ചോദ്യമാണ്. പ്രാമാണീകരണം നിരസിക്കുന്ന സെർവർ ഇവ രണ്ടുമല്ല, അതിനാൽ ആവർത്തിച്ചുള്ള പാസ്വേഡ് മാറ്റം പ്രാദേശിക സജീവീകരണ പ്രശ്നം പരിഹരിക്കാൻ കഴിയില്ല. തെറ്റായ തിരുത്ത് തിരഞ്ഞെടുക്കുന്നതാണ് നയ പ്രശ്നം പുനരിന്സ്റ്റാളാകുന്ന വഴി.
പാക്കേജ് മാറ്റത്തിന് ശേഷം പഴയ ബൈനറി അതിന്റെ സ്ഥാനത്ത് പകർത്തുന്നതിന് പകരം സുസംഗതവും പിന്തുണയുള്ളതുമായ ഇൻസ്റ്റാളേഷൻ പരിശോധിക്കുക. നിയന്ത്രിത പിന്നോട്ടുപോകൽ സ്ഥിരീകരിച്ച റിഗ്രഷനോടുള്ള സാധുവായ ഉത്തരമാണ്, പാക്കേജുകൾ അനുയോജ്യമായി നിന്നാൽ പിന്തുണയുള്ള പരിപാലനത്തിലേക്ക് മടങ്ങാനുള്ള വഴി ഉണ്ടെങ്കിൽ. ആ വഴി സേവനം തുടങ്ങുന്നത് നിലയ്ക്കുന്നതിന് മുമ്പ് സ്ഥാപിക്കുക, പിന്നീടല്ല.
മറ്റൊരു പ്ലാറ്റ്ഫോമിന് അതേ കോർ VPN ലൈബ്രറി Linux-ന്റെ ബസ് സേവനങ്ങൾ പങ്കിടാതെ പങ്കിടാം, അതിനാൽ Windows-ൽ സമാനമായി തോന്നുന്ന പരാജയം ഇതിനെപ്പറ്റി ഒന്നും പറയുന്നില്ല. D-Bus അവലോകനം കോൺഫിഗറേഷനുകൾക്കും സെഷനുകൾക്കുമായി വെളിപ്പെടുത്തുന്ന ഒബ്ജക്റ്റ് പാതകൾ രേഖപ്പെടുത്തുന്നു, ഈ രോഗനിർണയം നിൽക്കുന്ന വാസ്തുവിദ്യയുടെ ആ ഭാഗമാണത്. ഒരിക്കൽ വായിക്കുക, അടുത്ത പിശക് ഇതിനോട് ഇതിനകം ബന്ധിപ്പിച്ച ഘടകത്തോടെ വരും.