NM OpenVPN: സംരക്ഷിച്ച പ്രൊഫൈൽ നിങ്ങളുടെ .ovpn ഫയൽ അല്ല

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

ഫയൽ പ്രൊഫൈൽ അല്ല

ഇംപോർട്ട് ഒരു വിവർത്തനമാണ്, മൗണ്ട് അല്ല. പ്ലഗിൻ മനസ്സിലാക്കുന്ന ഓപ്ഷനുകൾ കണക്ഷന്റെ vpn.data നിഘണ്ടുവിൽ കീകളായി മാറുന്നു; മനസ്സിലാക്കാത്ത ഓപ്ഷനുകൾ ഒഴിവാക്കപ്പെടുന്നു അല്ലെങ്കിൽ മറ്റെവിടെയോ രേഖപ്പെടുത്തുന്നു, യഥാർത്ഥ പാത ഒരു റഫറൻസ് മാത്രമാണ്. പിന്നീട് സോഴ്സ് ഫയൽ എഡിറ്റ് ചെയ്യുന്നത് ഇതിനകം സംരക്ഷിച്ച കണക്ഷനിൽ ഒന്നും മാറ്റുന്നില്ല.

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

സംരക്ഷിച്ച പ്രൊഫൈൽ വായിക്കുക, ഡയലോഗ് അല്ല

nmcli -f connection.id,connection.uuid,vpn.service-type,vpn.data connection show office-vpn

രണ്ട് പ്രൊഫൈലുകൾ ഒരേ പേര് പങ്കിടുമ്പോൾ UUID ഉപയോഗിക്കുക, സേവന തരം നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന OpenVPN പ്ലഗിൻ ആണെന്ന് ഉറപ്പാക്കുക, യാദൃച്ഛികമായി ഇൻസ്റ്റാൾ ചെയ്ത മറ്റൊരു VPN തരം അല്ല. തുടർന്ന് എൻഡ്പോയിന്റ്, ട്രാൻസ്പോർട്ട്, സർട്ടിഫിക്കറ്റ് റഫറൻസുകൾ എന്നിവ പ്രവർത്തിക്കുന്ന വിളിയുമായി താരതമ്യം ചെയ്യുക.

ഗ്രാഫിക്കൽ എഡിറ്ററിൽ കാണുന്ന ഒരു മൂല്യം അത് സംരക്ഷിക്കപ്പെട്ടു എന്നതിന്റെ തെളിവല്ല. സംരക്ഷിക്കുക, വീണ്ടും തുറക്കുക, കമാൻഡ് ലൈനിലൂടെ അത് വീണ്ടും വായിക്കുക; ചരിത്രപരമായ സേവ് പിഴവുകൾ സംഭരിച്ച ഡാറ്റ പരിശോധിക്കാനുള്ള കാരണമാണ്, ഓരോ നിലവിലെ ബിൽഡിനും അതേ ബഗ് ഉണ്ടെന്നതിന്റെ തെളിവല്ല. പരിശോധനയ്ക്ക് ഒരു കമാൻഡ് മതി.

രണ്ട് കീകൾ, ഒപ്പം പ്രധാനമായ ഒരു ദിശ

TLS പ്രാമാണീകരണം ഉപയോഗിക്കുന്ന ഒരു കണക്ഷനിൽ, പ്ലഗിൻ പങ്കിട്ട കീയുടെ പാത ta -ൽ സൂക്ഷിക്കുന്നു, ദിശ ta-dir -ൽ, വിന്യാസം ഒരെണ്ണം ഉപയോഗിക്കുമ്പോൾ. രണ്ടും പ്രൊഫൈലിന്റെ ഡാറ്റ നിഘണ്ടുവിൽ ജീവിക്കുന്നു, രണ്ടും സെർവർ പ്രതീക്ഷിക്കുന്നതുമായി പൊരുത്തപ്പെടണം.

ദിശ ക്ലയന്റിൽ പ്രകടിപ്പിക്കുന്ന സെർവർ-വശത്തുള്ള തീരുമാനമാണ്. അടുത്തുള്ള പ്രൊഫൈലിൽ ഉണ്ടെന്ന കാരണത്താൽ ഒന്ന് തിരഞ്ഞെടുക്കുന്നത് പ്രവർത്തിക്കുന്ന കീ ഹാൻഡ്ഷേക്കിൽ പരാജയപ്പെടാൻ തുടങ്ങുന്ന വഴിയാണ്. സെർവർ കോൺഫിഗറേഷന് ദിശയില്ലെങ്കിൽ, ക്ലയന്റ് ഒരു ദിശ കണ്ടുപിടിക്കരുത്.

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

ഒരു എൻട്രി അപ്ഡേറ്റ് ചെയ്യുക, നിഘണ്ടു അല്ല

nmcli connection modify office-vpn +vpn.data 'ta=/etc/NetworkManager/certs/office-ta.key'
nmcli connection modify office-vpn +vpn.data 'ta-dir=1'

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

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

നിയന്ത്രണ-ചാനൽ മോഡുകൾ കൂട്ടിക്കലർത്തരുത്

tls-auth, tls-crypt, കൂടാതെ tls-crypt-v2 വ്യത്യസ്ത ക്രമീകരണങ്ങളാണ്. സമാനമായി കാണുന്ന ഒരു കീ ഫയൽ അവയെ പരസ്പരം മാറ്റാവുന്നതാക്കുന്നില്ല, മറ്റൊരു പ്രൊഫൈലിൽ ഫോർമാറ്റ് ചെയ്ത കീ ഉള്ളതിനാൽ TLS-Auth ഫീൽഡുകൾ പൂരിപ്പിക്കുന്നത് തെറ്റായ കീയോട് സാമ്യമുള്ള രീതിയിൽ പരാജയപ്പെടുന്ന പ്രൊഫൈൽ ഉണ്ടാക്കുന്നു.

സെർവറിന്റെ കോൺഫിഗറേഷനിലെ മോഡുമായി പൊരുത്തപ്പെടുന്ന പ്ലഗിൻ മാപ്പിംഗ് ഉപയോഗിക്കുക. മോഡ് വ്യക്തമല്ലാത്തപ്പോൾ ഫയലിന്റെ ആദ്യ വരിയിൽ നിന്ന് ഊഹിക്കുന്നതിന് പകരം സെർവർ ഉടമയോട് ചോദിക്കുക.

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