L2TP/IPsec പരാജയപ്പെടുന്നു: IPsec, ടണൽ പ്രാമാണീകരണം അല്ലെങ്കിൽ PPP ലോഗിൻ വേർതിരിക്കുക

ഒരു L2TP/IPsec കണക്ഷനുള്ളിൽ മൂന്ന് കാര്യങ്ങൾ പ്രാമാണീകരിക്കപ്പെടുന്നു, അവയിൽ ഒന്ന് മാത്രമാണ് ഡയൽ ചെയ്യുന്ന വ്യക്തിയെ ഉൾക്കൊള്ളുന്നത്. IPsec ടണലിന്റെ അറ്റങ്ങൾ തെളിയിക്കുന്നു, L2TP നിയന്ത്രണ കണക്ഷൻ സ്വന്തം രഹസ്യം കൊണ്ട് പീയറുകളെ വീണ്ടും തെളിയിക്കാം, തുടർന്ന് PPP സെഷനിലെ ഉപയോക്തൃ അക്കൗണ്ട് തെളിയിക്കുന്നു. ഏത് ഘട്ടത്തിലെ പരാജയവും ക്ലയന്റ് ഡയലോഗിൽ പൊതുവായ ലോഗിൻ പിശകായി തോന്നുകയും സർവർ ലോഗിൽ തികച്ചും വ്യത്യസ്തമായി കാണപ്പെടുകയും ചെയ്യും. ഘട്ടങ്ങൾ ക്രമത്തിൽ പൂർത്തിയാക്കി ആദ്യം പരാജയപ്പെടുന്നതിൽ നിർത്തുക, കാരണം പരിശോധിക്കാത്ത ഘട്ടത്തിന് താഴെയുള്ള ഓരോ ഘട്ടവും പരിശോധിക്കപ്പെട്ടിട്ടില്ല.

മൂന്ന് പ്രാമാണീകരണ ഘട്ടങ്ങൾ, മൂന്ന് വ്യത്യസ്ത ഐഡന്റിറ്റികൾ

IPsec മുൻകൂട്ടി പങ്കിട്ട കീ അല്ലെങ്കിൽ സർട്ടിഫിക്കറ്റ് ഉപയോഗിച്ച് അറ്റങ്ങൾ ആർക്കുള്ളതാണെന്ന് തെളിയിക്കുന്നു. ആ ഐഡന്റിറ്റി യന്ത്രങ്ങൾക്കോ ഗേറ്റ്വേകൾക്കോ ഉള്ളതാണ്, കീബോർഡിന് മുന്നിലുള്ള വ്യക്തിക്ക് ഒരിക്കലുമല്ല. ഈ ഘട്ടത്തിൽ പീയറുകൾക്ക് യോജിക്കാൻ കഴിയാത്തപ്പോൾ ഒരു L2TP പാക്കറ്റും കൈമാറ്റം ചെയ്യപ്പെടുന്നില്ല.

L2TP നിയന്ത്രണ കണക്ഷന് ഇരു അറ്റങ്ങൾക്കും ഉണ്ടായിരിക്കേണ്ട പങ്കിട്ട രഹസ്യത്താൽ നയിക്കപ്പെടുന്ന രണ്ടാമത്തെ, വേർതിരിച്ച വെല്ലുവിളി-പ്രതികരണ കൈമാറ്റം ചേർക്കാം.

RFC 2661 ആ നിയന്ത്രണ കണക്ഷൻ പ്രാമാണീകരണം ഐച്ഛികമാക്കുന്നു, ഇതേ തെറ്റ് രണ്ട് സർവറുകളിൽ വ്യത്യസ്ത ലക്ഷണങ്ങൾ നൽകുന്നതിന്റെ കാരണം വിശദീകരിക്കുന്നു. ടണൽ രഹസ്യം ഒരിക്കലും സജ്ജീകരിക്കാത്ത വിന്യാസം ഘട്ടം പൂർണ്ണമായി ഒഴിവാക്കുന്നു; ഒരു വശത്ത് മാത്രം സജ്ജീകരിച്ച വിന്യാസം PPP വാഗ്ദാനം ചെയ്യുന്നതിന് മുമ്പുതന്നെ പരാജയപ്പെടുന്നു. തുടർന്ന് PPP ഉപയോക്താവിനെ PAP, CHAP അല്ലെങ്കിൽ MSCHAPv2 ഉപയോഗിച്ച് പ്രാമാണീകരിച്ച് പേര് പ്രാദേശികമോ chap-secrets ലോ RADIUS-ലോ ആകാവുന്ന അക്കൗണ്ട് സ്റ്റോറിലേക്ക് കൈമാറുന്നു. ആ ഘട്ടത്തിലെ തെറ്റായ പാസ്വേഡ് ഇപ്പോഴും പ്രവർത്തിക്കുന്ന ടണലും പരാജയപ്പെട്ട സെഷനും നിങ്ങൾക്ക് നൽകുന്നു.

കോൺഫിഗർ എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് നിർത്തേണ്ട സ്ഥലം വായിക്കുക

സ്റ്റാറ്റസ് ഔട്ട്പുട്ട് strongSwan-ന്റേതാണോ Libreswan-ന്റേതാണോ എന്ന് അറിയാൻ ipsec --version ൽ തുടങ്ങുക. തുടർന്ന് ക്ലയന്റ് ഡയലോഗല്ല, സർവർ ലോഗ് വായിക്കുക, കാരണം ഏത് ഘട്ടം നിരസിച്ചു എന്ന് സർവർ രേഖപ്പെടുത്തുന്നു.

സാധാരണയായി ഒരു വരി ടിക്കറ്റ് തീരുമാനിക്കുന്നു: IKE അല്ലെങ്കിൽ നിർദ്ദേശങ്ങളെക്കുറിച്ചുള്ള പരാതി ആദ്യ ഘട്ടം, നിയന്ത്രണ കണക്ഷൻ സന്ദേശം രണ്ടാം ഘട്ടം, PPP രീതി അല്ലെങ്കിൽ അക്കൗണ്ട് നിരസിക്കൽ മൂന്നാം ഘട്ടം. ആ വരി സമയമുദ്രയോടെ ടിക്കറ്റിൽ പകർത്തുക. ക്ലയന്റ് വശത്ത് നിന്ന് ഊഹിക്കുന്നത് നിങ്ങൾക്ക് ഇപ്പോൾത്തന്നെയുള്ള ഏക തെളിവ് പാഴാക്കുന്നു.

കീ മെറ്റീരിയലും പാസ്വേഡുകളും ആ പേസ്റ്റിൽ നിന്ന് പുറത്ത് നിർത്തുക; ഘട്ടത്തിന്റെ പേര് ജോലിയെ നയിക്കുന്നു, ചോർന്ന മുൻകൂട്ടി പങ്കിട്ട കീ മോശം പരിണിതഫലങ്ങളോടെ ടിക്കറ്റ് വീണ്ടും തുറക്കുന്നു.

ആദ്യ ഘട്ടം: IPsec-ന് അസോസിയേഷൻ ഉണ്ടോ?

strongSwan-ൽ ipsec statusall അല്ലെങ്കിൽ Libreswan-ൽ ipsec whack --status പ്രവർത്തിപ്പിച്ച് പൂജ്യമല്ലാത്ത കൗണ്ടറുകളുള്ള സ്ഥാപിത ചൈൽഡ് അസോസിയേഷൻ തിരയുക. ip xfrm state രണ്ടിലും കെർണൽ കാഴ്ച കാണിക്കുന്നു. കൗണ്ടറുകൾ ഉയരുന്ന SA ജോഡി സ്ഥാപിച്ചിട്ടുണ്ടെങ്കിൽ ആദ്യ ഘട്ടം പൂർത്തിയായി, മുന്നോട്ട് പോകാം.

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

അസോസിയേഷൻ ഇല്ലാത്തിടത്തോളം നിർത്തുക. ആ ഘട്ടത്തിൽ PPP ഓപ്ഷനുകൾ എഡിറ്റ് ചെയ്യുന്നത് ഒന്നും മാറ്റുന്നില്ല, യഥാർത്ഥ തകരാർ അടുത്ത വ്യക്തിയിൽ നിന്ന് മറയ്ക്കുന്നു.

രണ്ടാം ഘട്ടം: L2TP നിയന്ത്രണ കണക്ഷൻ പ്രാമാണീകരിച്ചോ?

IPsec ഉയർന്നുകഴിഞ്ഞാൽ, സ്ഥാപിത അവസ്ഥയിലെത്തുന്ന നിയന്ത്രണ കണക്ഷനായി L2TP ഡീമണ് നിരീക്ഷിക്കുക, കാരണം അതിന് മുമ്പ് PPP ആരംഭിക്കാനാവില്ല. നിയന്ത്രണ കണക്ഷനിലെ നിരസിക്കൽ അർത്ഥം അറ്റങ്ങൾക്കിടയിൽ ടണൽ രഹസ്യം വ്യത്യസ്തമാണ്, അല്ലെങ്കിൽ ഒരു അറ്റം മറ്റേത് ഒരിക്കലും അയക്കാത്ത രഹസ്യം ആവശ്യപ്പെടുന്നു. ക്ലയന്റുകൾ പലപ്പോഴും shared secret എന്ന ലേബലുള്ള ഒരു ഫീൽഡ് കാണിക്കുന്നു, അത് സാധാരണയായി L2TP-യുടേതല്ല, IPsec-ന്റേതാണ്. അത് പൂരിപ്പിക്കുന്നത് ടണൽ രഹസ്യം സജ്ജീകരിക്കുന്നില്ല, മായ്ക്കുന്നത് അത് നിർജ്ജീവമാക്കുന്നുമില്ല.

ഇരു വശവും ടണൽ രഹസ്യം സജ്ജീകരിച്ചിട്ടില്ലെങ്കിൽ ഈ ഘട്ടം ഒഴിവാക്കി നിയന്ത്രണ കണക്ഷൻ പരാജയത്തെ പകരം എത്തിച്ചേരാനുള്ള പ്രശ്നമായി കണക്കാക്കുക. UDP 1701 ഡീമണിൽ എത്തുന്നുവെന്നും ഇരു അറ്റങ്ങളും ഒരേ എൻകാപ്സുലേഷനിൽ യോജിക്കുന്നുവെന്നും ഉറപ്പാക്കുക. ആ രണ്ട് വ്യവസ്ഥകളിൽ ഒന്നിനായി എഴുതിയ ഫയർവാൾ നിയമം പകുതി തുറക്കുന്ന കണക്ഷന്റെ സാധാരണ കാരണമാണ്.

PPP-യെക്കുറിച്ച് ചർച്ച തുടങ്ങുന്ന സെഷൻ മാത്രമാണ് ടണൽ ഘട്ടം യഥാർത്ഥത്തിൽ കടന്നത്.

മൂന്നാം ഘട്ടം: PPP അക്കൗണ്ട് നിരസിക്കുകയാണോ?

PPP പരാജയം പുറത്തുനിന്ന് വ്യത്യസ്തമായി കാണപ്പെടുന്നു: ടണൽ സ്ഥാപിതമാണ്, സെഷൻ തുടങ്ങുന്നു, ഡീമൺ പ്രാമാണീകരണ രീതിയുടെ പരാജയമോ അക്കൗണ്ട് നിരസിക്കലോ രേഖപ്പെടുത്തുന്നു. ആ സന്ദേശത്തിൽ പേരിട്ടിരിക്കുന്ന രീതി വായിക്കുക. PAP-ഉം CHAP-ഉം വ്യത്യസ്ത കാരണങ്ങളാൽ പരാജയപ്പെടുന്നു, ഒന്ന് നിരസിക്കുന്ന സർവർ അത് മാത്രം വാഗ്ദാനം ചെയ്യുന്ന ക്ലയന്റിനെയും നിരസിക്കും.

Linux സർവറിൽ, ഡീമൺ PPP-യ്ക്ക് നൽകുന്ന ഓപ്ഷൻ ഫയൽ, സാധാരണയായി /etc/ppp/options.xl2tpd, പരിശോധിച്ച് ഏത് രീതികൾ സ്വീകരിക്കുന്നു, അക്കൗണ്ടുകൾ എവിടെ പരിഹരിക്കുന്നു എന്ന് ഉറപ്പാക്കുക. RADIUS-ൽ ഉണ്ടെങ്കിലും പ്രാദേശിക രഹസ്യ ഫയലിൽ ഇല്ലാത്ത പേര് വൃത്തിയായി പരാജയപ്പെട്ട് തെറ്റായ പാസ്വേഡ് പോലെ തോന്നുന്നു. തുടർന്ന് ക്ലയന്റ് സർവർ സ്വീകരിക്കുന്ന രീതി വാഗ്ദാനം ചെയ്യുന്നുണ്ടോ, സർവർ ചർച്ച ചെയ്യാൻ വിസമ്മതിക്കുന്ന ശക്തമായ രീതിയല്ലെന്നും പരിശോധിക്കുക. ഈ ഘട്ടം നന്നാക്കാൻ മുൻകൂട്ടി പങ്കിട്ട കീ മാറ്റുന്നത് ഒരു ഉച്ചയ്ക്ക് ശേഷം പാഴാക്കുകയും ഒന്നും മാറ്റാതിരിക്കുകയും ചെയ്യും.

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