L2TP/IPsec PSK നിരസിക്കപ്പെട്ടു: ആദ്യം ഡയലോഗ്, പിന്നെ ഫയലുകൾ
സ്ക്രീനിലെ കീ ഇപ്പോഴും പഴയ രഹസ്യ ഫയലിനോ അദൃശ്യമായ ലൈൻ ബ്രേക്കിനോ തോൽക്കാം. NetworkManager ഫീൽഡിൽ നിന്ന് /etc/ipsec.d വരെ അത് പിന്തുടരുക.
അഡ്മിനിസ്ട്രേറ്ററുടെ സന്ദേശത്തിൽ നിന്നുള്ള പ്രീ-ഷെയേർഡ് കീ NetworkManager ഡയലോഗിൽ ഒട്ടിക്കുന്നു, കാണിക്കാൻ ബോക്സിൽ ടിക്ക് ചെയ്യുന്നു, അത് അക്ഷരം തോറും ഒത്തുപോകുന്നു. എന്നിട്ടും ടണൽ ഉയരുന്നതിന് മുമ്പ് കണക്ഷൻ പ്രാമാണീകരണ പരാജയത്തിൽ അവസാനിക്കുന്നു. ആദ്യമായി ഇത് കണ്ടപ്പോൾ കീ തെറ്റാണെന്ന് കരുതി; അങ്ങനെയായിരുന്നില്ല. ഡീമൻ യഥാർത്ഥത്തിൽ എന്ത് വായിക്കുന്നു എന്ന് മറ്റ് രണ്ട് കാര്യങ്ങൾ തീരുമാനിക്കുന്നു: ആ കണക്ഷനുവേണ്ടി പ്ലഗിൻ എഴുതുന്ന രഹസ്യ ഫയലും, മൂല്യം ഡയലോഗിലൂടെ മാറ്റമില്ലാതെ കടന്നുപോയോ എന്നതും.
താഴെയുള്ള വഴി കീയെ ഫീൽഡിൽ നിന്ന് ഫയലിലേക്ക് പിന്തുടരുന്നു, എവിടെ നഷ്ടപ്പെട്ടു എന്ന് പറയുന്നത് ആ ക്രമമാണ്. പരാജയപ്പെടുന്ന യന്ത്രത്തിൽ ഇത് ചെയ്യുക, പ്രവർത്തിക്കുന്ന യന്ത്രത്തിൽ അല്ല, കാരണം ആ രണ്ട് യന്ത്രങ്ങൾ തമ്മിലുള്ള വ്യത്യാസം സാധാരണയായി ഫയൽ ക്രമീകരണമാണ്, കീയല്ല.
ഡയലോഗിൽ നിന്ന് തുടങ്ങുക, പക്ഷേ ഫീൽഡിനെ വിശ്വസിക്കരുത്
കണക്ഷന്റെ IPsec ടാബ് തുറന്ന് കീ ഒട്ടിക്കുന്നതിന് പകരം വീണ്ടും ടൈപ്പ് ചെയ്യുക. ചാറ്റ് സന്ദേശം, PDF അല്ലെങ്കിൽ പാസ്വേഡ് മാനേജർ എന്നിവയിൽ നിന്ന് പകർത്തിയ കീയിൽ ഫീൽഡ് കാണിക്കാത്ത അവസാന ലൈൻ ബ്രേക്ക് ഉണ്ടാകാം, കാണുന്ന അക്ഷരങ്ങൾ ഇപ്പോഴും ശരിയായി തോന്നുന്നു.
പാസ്വേഡ് കാണിക്കുന്ന നിയന്ത്രണത്തിൽ ക്ലിക്ക് ചെയ്ത് സ്ട്രിംഗിന്റെ അവസാനം നോക്കുക, മധ്യമല്ല. കഴ്സർ ടെക്സ്റ്റിന് താഴെ ശൂന്യമായ വരി വിട്ടാൽ അത് മായ്ച്ച് അവസാന അക്ഷരം വീണ്ടും ടൈപ്പ് ചെയ്യുക. ആ ഒരു തിരുത്തൽ ഇത്തരം റിപ്പോർട്ടുകളുടെ ആശ്ചര്യകരമായ ഭാഗം പരിഹരിക്കുന്നു, ഏതെങ്കിലും ലോഗ് വായിക്കുന്നതിനേക്കാൾ കുറഞ്ഞ ചെലവേയുള്ളൂ.
കീ നീണ്ട വരികൾ മടക്കുന്ന ടിക്കറ്റ് സിസ്റ്റത്തിൽ നിന്നാണെങ്കിൽ മടക്കാത്ത ചാനലിലൂടെ അഭ്യർത്ഥിക്കുക. രണ്ട് സ്ട്രിംഗുകൾ അടുത്തടുത്ത് നോക്കുന്നതിന് പകരം നീളങ്ങൾ അഡ്മിനിസ്ട്രേറ്ററുമായി താരതമ്യം ചെയ്യുക; മടക്കുന്നിടത്ത് നഷ്ടപ്പെട്ട അക്ഷരം ആനുപാതിക ഫോണ്ടിൽ ദൃശ്യമല്ല.
/etc/ipsec.d ഉള്ളിലേക്ക് കീയെ പിന്തുടരുക
പ്ലഗിൻ PSK കമാൻഡ് ലൈനിലെ ആർഗ്യുമെന്റായി IPsec ഡീമന് ഒരിക്കലും നൽകുന്നില്ല. പകരം മൂല്യം രഹസ്യ ഫയലിൽ സൂക്ഷിക്കുകയും ഡീമൻ ആ ഫയൽ ഉൾപ്പെടുത്താൻ ക്രമീകരിക്കുകയും ചെയ്യുന്നു, ഇല്ലെങ്കിൽ /etc/ipsec.secrets-ൽ include വരി ചേർക്കുന്നു. ഡയലോഗ് സൂക്ഷിക്കുന്നത് ആ ഉണ്ടാക്കിയ ഫയലിലേക്കുള്ള ഇൻപുട്ടാണ്, ഉപയോഗത്തിലുള്ള മൂല്യമല്ല.
എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് എന്താണുള്ളതെന്ന് പട്ടികപ്പെടുത്തുക:
ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets
പ്ലഗിന്റെ പഴയ പതിപ്പുകൾ ഓരോ കണക്ഷനും ഒരു ഫയൽ എഴുതിയിരുന്നു, കണക്ഷന്റെ UUID പേരിൽ, ഉദാഹരണത്തിന് /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. ആപ്ലെറ്റിൽ പ്രൊഫൈൽ മായ്ക്കുന്നത് ആ ഫയൽ വിശ്വസനീയമായി മായ്ക്കുന്നില്ല. മുൻ സെർവറിൽ നിന്നുള്ള പഴയ ഫയൽ ഇപ്പോഴും ഡിസ്കിലും ഇപ്പോഴും ഉൾപ്പെടുത്തിയതുമാണെങ്കിൽ, ഡീമൻ നിങ്ങൾ ഇനി ഉപയോഗിക്കാത്ത പ്രൊഫൈലിന്റെ രഹസ്യം തിരഞ്ഞെടുക്കാം, കാണുന്ന ഫീൽഡ് ശരിയായിരിക്കെ കണക്ഷൻ പരാജയപ്പെടുന്നു.
1.2.12 മാറ്റം അപ്ഗ്രേഡുകൾക്ക് എന്ത് ചെയ്തുവെന്ന് മനസ്സിലാക്കുക
പ്ലഗിൻ പതിപ്പ് 1.2.12 ഓരോ കണക്ഷന്റെയും രഹസ്യ ഫയലുകൾ ഒരു പൊതു ഫയൽ കൊണ്ട് മാറ്റി, /etc/ipsec.d/ipsec.nm-l2tp.secrets. അപ്ഗ്രേഡ് UUID അനുസരിച്ചുള്ള പഴയ ഫയലുകൾ വൃത്തിയാക്കുന്നില്ല, നിലവിലുള്ള include /etc/ipsec.d/*.secrets വരി അവ ഇപ്പോഴും ഉൾപ്പെടുത്തുന്നു. പതിപ്പ് 1.2.16 സ്വതവേയുള്ള നിർദ്ദേശങ്ങളുടെ കൈകാര്യം മാറ്റി, രഹസ്യങ്ങളുടെ ക്രമീകരണമല്ല.
ആ ചരിത്രം ഒരേപോലെ തോന്നുന്ന പ്രൊഫൈലുള്ള രണ്ട് യന്ത്രങ്ങൾ വ്യത്യസ്തമായി പെരുമാറുന്നതിന്റെ കാരണം വിശദീകരിക്കുന്നു. കീ സമാനമാണ്; ഡീമൻ ഉൾപ്പെടുത്തുന്ന ഫയലുകളുടെ കൂട്ടം അല്ല. അനാഥ ഫയൽ നീക്കുമ്പോൾ മായ്ക്കുന്നതിന് പകരം മാറ്റിവയ്ക്കുക, കണക്ഷൻ സ്ഥിരീകരിക്കുക, പ്രവർത്തിക്കുന്ന അവസ്ഥ രേഖപ്പെടുത്തിയ ശേഷം അത് മായ്ക്കുക. പേരുമാറ്റം പഴയ മൂല്യം വീണ്ടെടുക്കാവുന്നതായി നിലനിർത്തുന്നു, തകരാർ മറ്റൊരിടത്താണെങ്കിൽ.
സംഭരണ ഫോർമാറ്റിന് ഉൾക്കൊള്ളാൻ കഴിയാത്ത അക്ഷരങ്ങൾ വേർതിരിക്കുക
പങ്കിട്ട രഹസ്യ സ്ട്രിംഗിനെക്കുറിച്ച് strongSwan ഡോക്യുമെന്റേഷൻ പറയുന്നത് മൂല്യത്തിൽ പുതിയ വരിയോ ഇരട്ട ഉദ്ധരണി അക്ഷരമോ ഉണ്ടാകരുത് എന്നാണ്. ഡോക്യുമെന്റിൽ നിന്ന് ഒട്ടിച്ച കീ സാധാരണ ഡയലോഗിൽ യാതൊരു ദൃശ്യവ്യത്യാസവുമില്ലാതെ ഇവ രണ്ടിൽ ഏതെങ്കിലും വഹിക്കാം.
1.2.12 മുതൽ സംഭരിച്ച മൂല്യം സാധാരണ ടെക്സ്റ്റല്ല. പ്ലഗിൻ ഫയലിൽ എത്തുന്നതിന് മുമ്പ് PSK base64-ൽ എൻകോഡ് ചെയ്യുന്നു, റിലീസ് കുറിപ്പുകൾ ആ എൻകോഡിംഗിനെയാണ് കീയിൽ ഇരട്ട ഉദ്ധരണി ഇപ്പോൾ സ്വീകാര്യമായതിന്റെ കാരണമായി കാണിക്കുന്നത്. അതിനാൽ ഫീൽഡിൽ ടൈപ്പ് ചെയ്ത ഉദ്ധരണി പ്രതിനിധീകരിക്കാവുന്നതാണ്; എല്ലാ നിയന്ത്രണ അക്ഷരങ്ങൾക്കും ഇത് ശരിയല്ല.
നീളം മറ്റൊരു നിയന്ത്രണമാണ്. L2TP/IPsec സോഫ്റ്റ്വെയറിൽ സാർവത്രികമായ ഏറ്റവും കുറഞ്ഞ പരിധിയില്ല: ചില ക്ലയന്റുകൾ ഇരുപത് അക്ഷരത്തിൽ കുറവുള്ള കീകൾ സ്വീകരിക്കുന്നു, ചില ഗേറ്റ്വേകൾ ഏറ്റവും കുറഞ്ഞ പരിധി അടിച്ചേൽപ്പിക്കുന്നു. ചെറിയ കീ നിരസിക്കപ്പെട്ടാൽ, ആ നിയമം സെർവർ നയത്തിന്റേതോ ആ ക്ലയന്റിന്റെ സാധുതാപരിശോധനയുടേതോ ആണ്, പ്രാദേശികമായി എന്തെങ്കിലും ഉയർത്തുന്നത് അത് മാറ്റില്ല.
ഏത് പ്രാമാണീകരണ പാളി പരാജയപ്പെട്ടുവെന്ന് വായിക്കുക
ആദ്യം ipsec --version പ്രവർത്തിപ്പിക്കുക, കാരണം strongSwan-ഉം Libreswan-ഉം വ്യത്യസ്ത ഫയൽനാമങ്ങളും സിന്റാക്സും ഉപയോഗിക്കുന്നു, ഒന്നിനുള്ള ഉപദേശം മറ്റൊന്നിനെ നശിപ്പിച്ചേക്കാം. പിന്നെ ക്ലയന്റിന്റെ സന്ദേശത്തിൽ നിന്നോ ഡീമന്റെ ലോഗിൽ നിന്നോ പരാജയഘട്ടം വായിക്കുക: പ്രീ-ഷെയേർഡ് കീയെക്കുറിച്ചുള്ള പരാതി നിരസിക്കപ്പെട്ട ഉപയോക്തൃനാമത്തിൽ നിന്നും പാസ്വേഡിൽ നിന്നും വ്യത്യസ്ത സംഭവമാണ്.
PSK ടണലിന്റെ അറ്റങ്ങളെ പ്രാമാണീകരിക്കുന്നു. ഉപയോക്തൃനാമവും പാസ്വേഡും L2TP-യ്ക്കുള്ളിലെ വ്യക്തിയെ പ്രാമാണീകരിക്കുന്നു, IPsec അസോസിയേഷൻ ഉയർന്നതിന് ശേഷം PPP അവ കൈകാര്യം ചെയ്യുന്നു. ശരിയായ PSK തെറ്റായ അക്കൗണ്ടിനൊപ്പം ഇപ്പോഴും പരാജയപ്പെടുന്നു, അക്കൗണ്ട് മാറ്റുന്നത് ഡീമൻ ഒരിക്കലും ശരിയായി വായിക്കാത്ത കീ നന്നാക്കില്ല.
ടിക്കറ്റ് അടയ്ക്കുമ്പോൾ നാലും എഴുതുക: പ്ലഗിൻ പതിപ്പ്, ഉപയോഗത്തിലുള്ള രഹസ്യ ഫയൽ, കീ വീണ്ടും ടൈപ്പ് ചെയ്തോ ഒട്ടിച്ചോ, പിശകിൽ പേരിട്ട പാളി. അപ്പോൾ ഈ വഴി പിന്നീട് ആവർത്തിക്കുന്ന ആർക്കും പ്രവർത്തിക്കുന്ന യന്ത്രവും പരാജയപ്പെടുന്ന യന്ത്രവും തമ്മിലുള്ള വ്യത്യാസത്തിലേക്ക് നേരിട്ട് പോകാം.