L2TP: മാരക സിഗ്നൽ 15, NO_PROPOSAL_CHOSEN, കാണാതായ modp1024

നിങ്ങളുടെ കണക്ഷൻ തൂങ്ങിനിൽക്കുന്നു, ക്ലയന്റ് പുറത്തുകടക്കുന്നു, സ്ക്രീനിലെ അവസാന വരി death_handler: Fatal signal 15 received ആണ്. ആ വരി തടസ്സത്തെക്കുറിച്ച് അറിയിക്കുന്നു, കാരണത്തെക്കുറിച്ചല്ല. IPsec ലോഗിൽ ഒരു വരി മുകളിൽ മിക്കവാറും എപ്പോഴും NO_PROPOSAL_CHOSEN ഉണ്ടാകും, ഈ ജോടി കൈമാറ്റത്തിന്റെ ഫേസ് 2-ലേക്ക് വിരൽ ചൂണ്ടുന്നു, അവിടെ ഇരുവശവും എൻക്രിപ്ഷനും ഹാഷും തിരഞ്ഞെടുക്കലുകൾ താരതമ്യം ചെയ്ത് പൊതുവായി ഒന്നുമില്ലെങ്കിൽ നിർത്തുന്നു. ആ ഘട്ടത്തിൽ ക്രെഡൻഷ്യലുകൾ ഇതുവരെ അയച്ചിട്ടില്ല, അതിനാൽ പാസ്വേഡ് വീണ്ടും ടൈപ്പ് ചെയ്യുന്നത് ഫലം മാറ്റില്ല.

Linux ക്ലയന്റിൽ സാധാരണയായി രണ്ട് കാര്യങ്ങൾ ആ കവല ഒഴിവാക്കുന്നു. പ്രൊഫൈൽ ആവശ്യപ്പെടുന്ന Diffie-Hellman ഗ്രൂപ്പ് ലോക്കൽ ഡീമൺ ഇനി നടപ്പാക്കാനിടയില്ല, അല്ലെങ്കിൽ ഫേസ് 1 നിർദ്ദേശം ഫേസ് 2 ഫീൽഡിൽ പ്രൊഫൈൽ വഹിക്കാം. രണ്ടും ലോഗിൽ തെളിവ് വിടുന്നു, ഒന്നും അക്കൗണ്ട് പ്രശ്നമല്ല.

ആ രണ്ട് സന്ദേശങ്ങൾ യഥാർത്ഥത്തിൽ എന്ത് പറയുന്നു

IKE ഘട്ടങ്ങളായി ചർച്ച ചെയ്യുന്നു. ഫേസ് 1 സംരക്ഷിത ചാനൽ നിർമ്മിച്ച് സ്വന്തം അൽഗോരിതങ്ങൾ തിരഞ്ഞെടുക്കുന്നു; ഫേസ് 2, അതായത് ചൈൽഡ് SA, പ്രത്യേക സെറ്റിന് കീഴിൽ ട്രാഫിക് കൊണ്ടുപോകുന്നു. NO_PROPOSAL_CHOSEN എന്നത് വാഗ്ദാനം ചെയ്ത സംയോജനങ്ങളിൽ ഒന്നും സ്വീകാര്യമല്ലാത്തപ്പോൾ ഉത്തരം നൽകുന്നയാൾ തിരികെ നൽകുന്ന അറിയിപ്പാണ്, അത് INFORMATIONAL കൈമാറ്റത്തിനുള്ളിൽ [ HASH N(NO_PROP) ] ആയി പ്രത്യക്ഷപ്പെടുന്നു.

സിഗ്നൽ 15 മറ്റൊരു സംഭവമാണ്: എന്തോ ലോക്കൽ പ്രോസസ്സിനോട് നിർത്താൻ പറഞ്ഞു, ഹാൻഡ്ലർ അത് രേഖപ്പെടുത്തി. രണ്ട് വരികളും ഒരുമിച്ച് വരുമ്പോൾ ക്രമം കാരണാത്മകമാണ്, ആദ്യം നിരസിക്കൽ, പിന്നെ ഓഫാക്കൽ.

ക്രെഡൻഷ്യലുകളിൽ തൊടുന്നതിന് മുമ്പ് ചർച്ച വായിക്കുക

ഡീമൺ എഴുതുന്നിടത്ത് ലോഗ് ലെവൽ ഉയർത്തി, ഔട്ട്പുട്ട് നിരീക്ഷിച്ചുകൊണ്ട് വീണ്ടും കണക്ട് ചെയ്യുക. NetworkManager ഹോസ്റ്റിൽ L2TP പ്ലഗിൻ ആ ലെവൽ ബാക്കെൻഡിന് നൽകുന്നു, സന്ദേശങ്ങൾ വിതരണത്തിനനുസരിച്ച് journal-ലോ പരമ്പരാഗത syslog ഫയലിലോ എത്തുന്നു. ഇവയിലേതെങ്കിലും കൈമാറ്റം കാണിക്കും: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' അല്ലെങ്കിൽ tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

pluto എന്ന് പേരിടുന്ന വരി libreswan-ൽ നിന്ന് വരുന്നു, charon strongSwan-ൽ നിന്ന്, രണ്ടും ഒരേ അവസ്ഥ വ്യത്യസ്ത വാക്കുകളിൽ വിവരിക്കുന്നു. തിരയാൻ യോഗ്യമായ രൂപം കാണാത്ത ഗ്രൂപ്പിനെ പേരിടുന്നതാണ്, ഉദാഹരണത്തിന് algorithm 'modp1024' is not supported, കാരണം അത് അവ്യക്തമായ പരാജയത്തെ വ്യക്തമാക്കുന്നു.

modp1024 എങ്ങോട്ട് പോയി

Diffie-Hellman ഗ്രൂപ്പ് 2 വളരെ ദുർബലമായതിനാൽ നിരവധി വിതരണങ്ങൾ 3.30 മുതൽ അത് libreswan-ലേക്ക് കംപൈൽ ചെയ്യുന്നത് നിർത്തി. അപ്പോൾ വർഷങ്ങൾക്ക് മുമ്പ് എഴുതിയതോ aes128-sha1-modp1024 മാത്രം പട്ടികപ്പെടുത്തുന്ന ഗേറ്റ്വേ ഗൈഡിൽ നിന്ന് എടുത്തതോ ആയ പ്രൊഫൈൽ ലോക്കൽ ഡീമണിൽ നിന്ന് അതിന് ഒട്ടും ചെയ്യാൻ കഴിയാത്ത എന്തോ ആവശ്യപ്പെടുന്നു. പുതിയ NetworkManager-l2tp ബിൽഡുകൾ ആ ഫലം കൂടുതൽ സാധ്യമാക്കുന്നു: 1.2.16 മുതൽ അവർ സെറ്റ് Windows 10, iOS ശൈലിയിലുള്ള നിർദ്ദേശങ്ങളാൽ മാറ്റി, libreswan കണ്ടെത്തിയാൽ ഉടൻ modp1024 ഒഴിവാക്കുന്നു. എതിർവശം പലപ്പോഴും നിരപരാധിയാണ്, ഇപ്പോഴും നിങ്ങൾ കോൺഫിഗർ ചെയ്ത അതേ ഗ്രൂപ്പ് നൽകുന്നു.

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

വ്യത്യസ്ത സ്വാധീനമുള്ള രണ്ട് അറ്റകുറ്റപ്പണികൾ

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

രണ്ടാമത്തെ അറ്റകുറ്റപ്പണി strongSwan ഇൻസ്റ്റാൾ ചെയ്ത് പഴയ ഗേറ്റ്വേ എത്താവുന്നതാക്കി നിർത്തുന്നു, അതിന്റെ പാക്കേജുകൾ മിക്ക വിതരണങ്ങളിലും ഇപ്പോഴും ഗ്രൂപ്പ് 2 നടപ്പാക്കുന്നു. അത് ഡീമൺ മാറ്റമാണ്, അതിനാൽ വിലയുണ്ട്: നീക്കം ചെയ്യുന്നതിന് മുമ്പ് ഹോസ്റ്റിലെ മറ്റ് ടണലുകൾ libreswan കോൺഫിഗറേഷനെ ആശ്രയിക്കുന്നുണ്ടോ എന്ന് ഉറപ്പാക്കുക, Fedora-യിൽ NetworkManager-ഉം strongSwan പ്ലഗിനും ഇടയിൽ SELinux നിരസിക്കലുകൾ പ്രതീക്ഷിക്കുക. ആ നിരസിക്കലുകൾ IKE ട്രെയ്സിലല്ല, ഓഡിറ്റ് ലോഗിൽ പ്രത്യക്ഷപ്പെടുന്നു, അതുകൊണ്ടാണ് വിജയകരമായ ഇൻസ്റ്റാളിന് ശേഷം ഉടൻ ടണൽ തകർന്നതായി തോന്നാം. പ്രവർത്തിക്കുന്ന ക്രമം ആദ്യം dnf install strongswan, പിന്നെ rpm -e libreswan ആണ്.

പൊരുത്തപ്പെടുന്ന നിർദ്ദേശ സ്ട്രിംഗുകൾ, അവയ്ക്ക് ചുറ്റുമുള്ള കെണികൾ

ഫീൽഡുകൾ കൈകൊണ്ട് പൂരിപ്പിക്കേണ്ടിവരുമ്പോൾ ഫേസ് 1-ഉം ഫേസ് 2-ഉം വ്യത്യസ്ത മൂല്യങ്ങൾ എടുക്കുന്നു. Meraki ശൈലിയിലുള്ള എതിർവശത്തിനെതിരെ പ്രവർത്തിക്കുമെന്ന് അറിയപ്പെടുന്ന ജോടി ഫേസ് 1-ൽ aes128-sha1-modp1024-ഉം അതിന് പിന്നിൽ 3des-sha1-modp1024-ഉം നൽകുന്നു, രണ്ടും സെറ്റ് കർശനമാക്കുന്ന ആശ്ചര്യചിഹ്നത്താൽ അടയ്ക്കുന്നു, അതിനാൽ ആ നിർദ്ദേശങ്ങൾ മാത്രം അയക്കപ്പെടുന്നു.

പിന്നെ ഫേസ് 2 അതേ കർശന അടയാളത്തോടെ, Diffie-Hellman പ്രത്യയമില്ലാതെ aes128-sha1, 3des-sha1 എന്നിവയിലേക്ക് ചുരുങ്ങുന്നു. -modp1024 വഹിക്കുന്ന ഫേസ് 2 വരി തെറ്റായ ഫീൽഡിലുള്ള ഫേസ് 1 മൂല്യമാണ്, ഉത്തരം നൽകുന്നയാൾ ഓരോ വീണ്ടും ശ്രമത്തിലും അത് നിരസിക്കുന്നു. ആ വരി രണ്ടാമത്തെ പ്രൊഫൈലിലേക്ക് പകർത്തുക, രണ്ടാമത്തെ പ്രൊഫൈലും അതേ രീതിയിൽ പരാജയപ്പെടും, അങ്ങനെ ഒരു ടൈപ്പിംഗ് പിശക് മുഴുവൻ കപ്പലിന്റെ സംഭവമാകുന്നു.

മറ്റ് തകരാറുകൾ നിർദ്ദേശ പൊരുത്തക്കേടല്ലാതെ അതേ പോപ്പപ്പ് ധരിക്കുന്നു. KDE-യിൽ പ്ലഗിൻ ഇൻസ്റ്റാൾ ചെയ്തിട്ടും L2TP തരം ലിസ്റ്റ് ചെയ്യപ്പെടാം, അതേസമയം ഓരോ കണക്ഷനും ഉടൻ മരിക്കുന്നു, കാരണം കണക്ഷൻ എഡിറ്ററും റൺടൈം സഹായികളും വെവ്വേറെ പാക്കേജുകളായി വരുന്നു. സ്ക്രീനില്ലാത്ത ഹോസ്റ്റുകൾ പ്രവർത്തിക്കുന്ന ഡെസ്ക്ടോപ്പിൽ നിന്നുള്ള പ്രൊഫൈൽ വീണ്ടും ഉപയോഗിക്കാം: അത് /etc/NetworkManager/system-connections/-ൽ നിന്ന് പകർത്തി, മോഡ് 600-ലേക്ക് സെറ്റ് ചെയ്ത്, പിന്നെ nmcli con reload പ്രവർത്തിപ്പിക്കുക. nmcli con up id work-l2tp ഉപയോഗിച്ച് അത് ഉയർത്തുക, കാരണം നഗ്നരൂപത്തിന് UUID വേണം, കാലഹരണപ്പെട്ട ഏതെങ്കിലും ifname എൻട്രി നീക്കം ചെയ്യുക, അല്ലെങ്കിൽ ബാക്കിയെല്ലാം ശരിയായിരിക്കെ മാനേജർ Could not find source connection എന്ന് മറുപടി നൽകും.

മുൻകൂട്ടി പങ്കിട്ട കീ വ്യക്തമായ ടെക്സ്റ്റായോ 0s-ന് ശേഷം base64 ആയോ സൂക്ഷിക്കാം; രണ്ട് രൂപങ്ങളും പ്രവർത്തിക്കുന്നു, പക്ഷേ മൂല്യം ഗേറ്റ്വേയുമായി ബൈറ്റ് ബൈറ്റ് പൊരുത്തപ്പെടണം, അതിനൊപ്പം നിങ്ങൾ പകർത്തിയ അവസാന ഇടവേളകൾ ഉൾപ്പെടെ.