L2TP NO_PROPOSAL_CHOSEN: യഥാർത്ഥത്തിൽ ഏത് ഘട്ടമാണ് പരാജയപ്പെട്ടത്?
ഒരു നിർദ്ദേശം നിരസിക്കപ്പെട്ടു എന്ന് അറിയിപ്പ് പറയുന്നു, ഏതാണെന്നല്ല. ഘട്ടം അറിയാൻ ബാക്കെൻഡ് ലോഗ് വായിക്കുക, തുടർന്ന് ഗേറ്റ്‌വേ നടത്തുന്നയാളുമായി സ്യൂട്ടുകൾ താരതമ്യം ചെയ്യുക.
NO_PROPOSAL_CHOSEN ഏതെങ്കിലും PPP ഉപയോക്തൃനാമം പരിശോധിക്കുന്നതിന് മുമ്പേ എത്തുന്നു, ഇത് ഉപയോഗപ്രദമായ വസ്തുതയും അതോടൊപ്പം സന്ദേശം തെറ്റിദ്ധരിപ്പിക്കുന്നതിനുള്ള കാരണവുമാണ്. ഒരു ഭാഗം ഒരു നിർദ്ദേശം നിരസിച്ചു എന്ന് അത് റിപ്പോർട്ട് ചെയ്യുന്നു; ഏത് പാരാമീറ്റർ ഒത്തുപോയില്ല എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നില്ല, നിരസിക്കൽ IKE അസോസിയേഷൻ നിർമ്മിക്കുമ്പോൾ സംഭവിച്ചതാണോ അതല്ല ട്രാഫിക് സംരക്ഷണത്തെക്കുറിച്ചുള്ള ചർച്ചയിൽ പിന്നീട് സംഭവിച്ചതാണോ എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നുമില്ല. ഈ രണ്ട് സാധ്യതകൾക്ക് പിന്നിൽ രണ്ട് വ്യത്യസ്ത പരിഹാരങ്ങളുണ്ട്, അവയിൽ ഒന്ന് മാത്രമാണ് ആളുകൾ ആദ്യം എത്തിപ്പിടിക്കുന്ന PFS ചെക്ക്ബോക്സുമായി ബന്ധപ്പെട്ടിരിക്കുന്നത്.
ഒരു സന്ദേശം, രണ്ട് നിർദ്ദേശ കൂട്ടങ്ങൾ
IKEv1 L2TP/IPsec ക്രമീകരണത്തിൽ രണ്ട് ചർച്ചകൾ തുടർച്ചയായി നടക്കുന്നു. ഘട്ടം 1 എൻക്രിപ്ഷൻ അൽഗോരിതം, സമഗ്രത അൽഗോരിതം, Diffie-Hellman ഗ്രൂപ്പ് എന്നിവയിൽ നിന്ന് IKE സുരക്ഷാ അസോസിയേഷൻ നിർമ്മിക്കുന്നു. തുടർന്ന് ഘട്ടം 2 ട്രാഫിക് എങ്ങനെ സംരക്ഷിക്കപ്പെടും എന്നതിനെക്കുറിച്ച് ചർച്ച ചെയ്യുന്നു, PFS ആവശ്യകത ആ രണ്ടാമത്തെ സംഭാഷണത്തിനാണ്.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
ഘട്ടങ്ങൾ തുടർച്ചയായതിനാൽ, പരാജയത്തിന്റെ സ്ഥാനം ഏത് പട്ടിക താരതമ്യം ചെയ്യണമെന്ന് പറയുന്നു. സന്ദേശത്തിന്റെ മുഴുവൻ രോഗനിർണ്ണയ മൂല്യം അതിലാണ്, ഏതെങ്കിലും ക്രമീകരണം തൊടുന്നതിന് മുമ്പ് അത് പുറത്തെടുക്കുന്നത് ഉചിതമാണ്.
PFS ചെക്ക്ബോക്സിന് ഘട്ടം 1 നന്നാക്കാൻ കഴിയാത്തത് എന്തുകൊണ്ട്
PFS പ്രവർത്തനരഹിതമാക്കുന്നത് ഘട്ടം 2 ന്റെ ഒരു ഗുണം മാറ്റുന്നു. കക്ഷികൾ ഘട്ടം 1 ൽ ഒരിക്കലും യോജിച്ചിട്ടില്ലെങ്കിൽ ESP സംഭാഷണം ഒരിക്കലും നടക്കുന്നില്ല, അതിനാൽ ചെക്ക്ബോക്സിന് നിരസിക്കലിൽ യാതൊരു സ്വാധീനവുമില്ല, അതുകൊണ്ടാണ് അത് മാറ്റുമ്പോൾ അതേ പിശക് വേറൊരു സമയമുദ്രയോടെ വരുന്നത്.
വിപരീതമായ തെറ്റും അത്രതന്നെ സാധാരണമാണ്. വിജയകരമായ IKE അസോസിയേഷൻ ESP നിർദ്ദേശം സ്വീകാര്യമാണെന്ന് തെളിയിക്കുന്നില്ല, ഘട്ടം 2 ന്റെ ഗ്രൂപ്പ് ഒത്തുപോകുന്നു എന്ന് ഒരിക്കലും തെളിയിക്കുന്നുമില്ല. സ്ഥാപിതമായ മാനേജ്മെന്റ് ടണൽ ഘട്ടം 1 നെക്കുറിച്ചുള്ള തെളിവായി മാത്രം പരിഗണിക്കുക. ആളുകൾ പച്ച വരി «ടണൽ പ്രവർത്തിക്കുന്നു» എന്ന് വായിക്കുന്നു, തുടർന്ന് രണ്ടാമത്തെ ചർച്ച തുടങ്ങിയിട്ടില്ലെന്ന് ആരും പറയാത്തതിനാൽ തെറ്റായ ഘട്ടത്തിൽ ഒരു മണിക്കൂർ ചെലവഴിക്കുന്നു.
അൽഗോരിതങ്ങൾ തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് ലോഗ് വായിക്കുക
നിരസിക്കലിന് തൊട്ടുമുമ്പുള്ള സന്ദേശങ്ങൾ കണക്ഷൻ യഥാർത്ഥത്തിൽ കൈകാര്യം ചെയ്യുന്ന ബാക്കെൻഡിൽ നിന്ന് ശേഖരിച്ച് അവയെ അതേ ശ്രമവുമായി ബന്ധിപ്പിക്കുക. ആ ബന്ധമില്ലാതെ നിങ്ങൾ മറ്റൊരു കണക്ഷന്റെ ചരിത്രം വായിക്കുകയും അതിൽ നിന്ന് നിഗമനങ്ങളിൽ എത്തുകയും ചെയ്യുന്നു.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanആ വരികളിൽ നിന്ന് രണ്ട് ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുക: ഘട്ടം 1 ന്റെ അസോസിയേഷൻ സ്ഥാപിതമായോ, ഏത് കൈമാറ്റമാണ് പരാജയപ്പെട്ടത്. ഈ രണ്ട് ഉത്തരങ്ങൾ തിരച്ചിലിനെ ഒരു ആട്രിബ്യൂട്ട് പട്ടികയിലേക്ക് ചുരുക്കുന്നു. ചുറ്റുമുള്ള സന്ദർഭമില്ലാത്ത വെറും അറിയിപ്പിന് അത് ചെയ്യാനാകില്ല, ഫോറം ത്രെഡിൽ നിന്ന് ഒരു നിർദ്ദേശം പരീക്ഷിക്കുന്നത് എത്ര ആകർഷകമായാലും. മറ്റൊരു ബാക്കെൻഡുള്ള യന്ത്രത്തിൽ നിന്ന് പ്രവർത്തിക്കുന്ന സ്ട്രിംഗ് പകർത്തുന്നത് സാധാരണയായി ഒരു നിരസിക്കലിനെ മറ്റൊന്നുകൊണ്ട് മാറ്റിസ്ഥാപിക്കുന്നു, അൽപ്പം വൈകി.
ബാക്കെൻഡിന്റെ വാക്യഘടന യാത്ര ചെയ്യുന്നില്ല
എന്തെങ്കിലും താരതമ്യം ചെയ്യുന്നതിന് മുമ്പ് NetworkManager-l2tp പതിപ്പും IPsec ബാക്കെൻഡ് പതിപ്പും രേഖപ്പെടുത്തുക. Libreswan ഉം strongSwan ഉം നിർദ്ദേശ വാക്യഘടനയോ സമാന അൽഗോരിതം കൂട്ടങ്ങളോ പങ്കിടുന്നില്ല, അതിനാൽ ഒന്നിൽ പ്രവർത്തിക്കുന്ന സ്ട്രിംഗ് മറ്റൊന്നിൽ വാക്യഘടനാ പിശകാണ്. ഇൻസ്റ്റാൾ ചെയ്ത ബാക്കെൻഡ് നയപ്രകാരം IKEv1 നിരസിച്ചേക്കാം, അപ്പോൾ ഒരു നിർദ്ദേശവും ഒരിക്കലും സ്വീകരിക്കപ്പെടുകയില്ല.
പ്രോജക്റ്റിന്റെ README ആ ബാക്കെൻഡ് വ്യത്യാസങ്ങൾ രേഖപ്പെടുത്തുകയും ഘട്ടം 1, ഘട്ടം 2 എന്നിവയുടെ ഫീൽഡുകൾ വേർതിരിച്ച് സൂക്ഷിക്കുകയും ചെയ്യുന്നു. അതിനെ ഘടനയുടെ രേഖയായി വായിക്കുക, എല്ലാ ചരിത്രപരമായ സൈഫറും ദുർബലമായ ഗ്രൂപ്പും പ്രവർത്തനക്ഷമമാക്കാനുള്ള ക്ഷണമായി അല്ല, കാരണം അങ്ങനെ ചെയ്താൽ മാത്രം വിജയിക്കുന്ന കണക്ഷൻ നിർമ്മിക്കാൻ ആവശ്യപ്പെട്ട കണക്ഷനല്ല.
സ്യൂട്ടിൽ യോജിക്കുക, തുടർന്ന് ഘട്ടങ്ങൾ പരിശോധിക്കുക
ഏത് IKE, ESP സ്യൂട്ടുകളാണ് പിന്തുണയ്ക്കപ്പെടുന്നതും അംഗീകരിക്കപ്പെട്ടതും എന്ന് ഗേറ്റ്‌വേ ഓപ്പറേറ്ററിനോട് ചോദിക്കുക, തുടർന്ന് ആ ഉത്തരം ക്ലയന്റിന്റെ കോൺഫിഗറേഷൻ ഫയലുമായല്ല, അതിന്റെ ഫലപ്രദമായ നിർദ്ദേശങ്ങളുമായി താരതമ്യം ചെയ്യുക. അഭിപ്രായവ്യത്യാസം പ്രത്യേകിച്ച് ഘട്ടം 2 ന്റെ PFS നെക്കുറിച്ചാണെങ്കിൽ, പിന്തുണയ്ക്കുന്ന ഗ്രൂപ്പിലോ വ്യക്തമായി അംഗീകരിച്ച PFS-രഹിത നയത്തിലോ തീരുമാനിക്കുക. പിശകിന്റെ പേരിൽ നിന്ന് നയം അനുമാനിക്കരുത്.
ഏകമാത്രമായ ഓവർലാപ്പിന് സംഘടന ഇനി സ്വീകരിക്കാത്ത ക്രിപ്റ്റോഗ്രാഫി ആവശ്യമാണെങ്കിൽ, തീരുമാനം ഗേറ്റ്‌വേയുടേതോ പ്രോട്ടോക്കോൾ മാറ്റത്തിന്റേതോ ആണ്. എന്തെങ്കിലും ചർച്ച നടക്കുന്നതുവരെ ക്ലയന്റ് സ്ട്രിംഗ് വിശാലമാക്കുന്നത് അറിയപ്പെടുന്ന ദുർബലത ഒപ്പം പച്ച ടിക്കോടെ അയക്കാനുള്ള വഴിയാണ്.
യഥാർത്ഥ പൊരുത്തക്കേട് തിരുത്തിയ ശേഷം, L2TP ഉം PPP ഉം അന്വേഷിക്കുന്നതിന് മുമ്പ് IPsec സ്ഥാപനം സ്ഥിരീകരിക്കുക, തുടർന്നുള്ള ഏത് പ്രാമാണീകരണ നിരസിക്കലും അടുത്ത ഘട്ടത്തിനുള്ളതായി കണക്കാക്കുക. തുടർന്ന് അംഗീകരിച്ച പരിശോധനാ പ്രക്രിയയിൽ പുതുക്കൽ പരീക്ഷിക്കുക, കാരണം ആദ്യ അസോസിയേഷന്റെ സ്ഥാപനം അതിന്റെ ബാക്കി ആയുസ്സിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.