PPP CHAP മാത്രം MPPE ആവശ്യകത എന്തുകൊണ്ട് നിറവേറ്റാൻ കഴിയില്ല

എൻക്രിപ്ഷൻ നിർബന്ധിക്കുന്ന ഒരു PPTP പ്രൊഫൈൽ സാധാരണയായി അതേ സ്ഥലത്ത് പരാജയപ്പെടുന്നു: MPPE-ക്ക് ആവശ്യമായ കീ മെറ്റീരിയൽ ഒരിക്കലും ഉത്പാദിപ്പിക്കാത്ത ഒരു പ്രാമാണീകരണ കൈമാറ്റത്തിന് PPP സമ്മതിക്കുന്നു. ടണൽ പകുതി ജീവനുള്ളതായി തോന്നുന്നു, പാസ്വേഡ് സ്വീകരിക്കപ്പെടുന്നു, ഏതെങ്കിലും ട്രാഫിക് അതിലൂടെ കടക്കുന്നതിന് മുമ്പ് ലിങ്ക് വീഴുന്നു. എന്തെങ്കിലും കണക്റ്റ് ചെയ്യുന്നതുവരെ CHAP ഡ്രോപ്പ്ഡൗൺ ലേക്ക് എത്തുന്നത് യഥാർത്ഥ വൈകല്യം മറയ്ക്കുന്നു, അത് പ്രാമാണീകരണ രീതിക്കും സംരക്ഷണ നയത്തിനും ഇടയിലുള്ള ഒരു കരാറാണ്. താഴെയുള്ള പരിശോധനകൾ അടുത്തതിനേക്കാൾ വിലകുറഞ്ഞ കാരണം ഓരോന്നും ഒഴിവാക്കുന്ന വിധത്തിൽ ക്രമീകരിച്ചിരിക്കുന്നു.

ഒരു PPTP കണക്ഷനുള്ളിൽ രണ്ട് ചർച്ചകൾ നടക്കുന്നു

PPTP ഒരു GRE ടണലിനുള്ളിൽ സാധാരണ PPP സെഷൻ വഹിക്കുന്നു, രണ്ടും വെവ്വേറെ ചർച്ച ചെയ്യുന്നു. പുറം പാളി പാക്കറ്റുകൾ എങ്ങനെ എൻകാപ്സുലേറ്റ് ചെയ്യുന്നു, ഏത് നിയന്ത്രണ ചാനൽ നിലവിലുണ്ട് എന്ന് തീരുമാനിക്കുന്നു; ഉള്ളിലെ PPP സെഷൻ ആരാണ് പങ്കാളി, മുകളിൽ ഏത് സംരക്ഷണം സഞ്ചരിക്കുന്നു എന്ന് തീരുമാനിക്കുന്നു. അതിനാൽ പാസ്വേഡ് അഭ്യർത്ഥന ഉള്ളിലെ പാളിയെക്കുറിച്ച് മാത്രം എന്തെങ്കിലും തെളിയിക്കുന്നു, പൂർത്തിയായ പുറം ഹാൻഡ്ഷേക്ക് രണ്ടിനെക്കുറിച്ചും ഒന്നും തെളിയിക്കുന്നില്ല. പ്രൊഫൈലുകൾ ഇവിടെ പരാജയപ്പെടുന്നത് ആളുകൾ ടണൽ ഡീബഗ് ചെയ്യുമ്പോൾ അഭിപ്രായവ്യത്യാസം PPP-ക്കുള്ളിൽ ഇരിക്കുന്നതുകൊണ്ടാണ്.

സാധാരണ CHAP എന്നത് RFC 1994-ലെ വെല്ലുവിളി-പ്രതികരണ കൈമാറ്റമാണ്, പങ്കിട്ട രഹസ്യത്തിന്മേലും മറ്റൊന്നുമില്ലാതെയും നിർമ്മിച്ചത്. MS-CHAPv2 വ്യത്യസ്ത സന്ദേശങ്ങളും വ്യത്യസ്ത ഔട്ട്പുട്ടും ഉള്ള മറ്റൊരു കൈമാറ്റമാണ്, RFC 2759-ൽ മാനകീകരിച്ചത്. രണ്ട് പേരുകളിലെയും പങ്കിട്ട വാക്കാണ് വയറിൽ അവർക്ക് പൊതുവായുള്ള ഏക കാര്യം. ഏത് പേരും കൈമാറ്റം എന്ത് ഉത്പാദിപ്പിക്കുന്നു എന്ന് പറയുന്നില്ല, അതാണ് ഏക പ്രധാന ഭാഗം.

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

ആവശ്യമായ രീതിയെ അത് ഉത്പാദിപ്പിക്കാൻ കഴിയുന്ന കീകളുമായി ചേർക്കുക

MPPE കീകൾ പൊതുവായി PPP-യുടെ ഒരു സ്വത്തല്ല. Microsoft CHAP കുടുംബത്തിന് വ്യുൽപ്പത്തി RFC 3079-ൽ വ്യക്തമാക്കിയിരിക്കുന്നു, അത് ഇൻപുട്ടായി പങ്കിട്ട രഹസ്യത്തിന് പകരം MS-CHAP കൈമാറ്റത്തിന്റെ ഔട്ട്പുട്ട് എടുക്കുന്നു. EAP രീതികൾ മറ്റൊരു വഴിയിലൂടെ അതേ സ്ഥലത്ത് എത്തുന്നു, പ്രാമാണീകരണ സർവർ കീകൾ MS-MPPE-Recv-Key, MS-MPPE-Send-Key എന്നീ ആട്രിബ്യൂട്ടുകളായി തിരികെ നൽകുന്നു. സാധാരണ CHAP രണ്ട് വഴികളിലും പ്രത്യക്ഷപ്പെടുന്നില്ല, ഈ പൊരുത്തക്കേട് നിലനിൽക്കാനുള്ള മുഴുവൻ കാരണം അതാണ്.

കീ നൽകാൻ കഴിയുന്ന എല്ലാ രീതിയും നിരസിച്ചുകൊണ്ട് MPPE ആവശ്യപ്പെടുന്ന ഒരു കോൺഫിഗറേഷൻ ആന്തരികമായി വൈരുദ്ധ്യാത്മകമാണ്. pppd ആ വൈരുദ്ധ്യം കീകൾ കെട്ടിച്ചമച്ചല്ല, ലിങ്ക് നിരസിച്ചാണ് പരിഹരിക്കുന്നത്, അതിനാൽ ദൃശ്യമായ ഫലം പ്രാമാണീകരിച്ച് പിന്നീട് നെറ്റ്വർക്ക് ഘട്ടത്തിൽ അവസാനിക്കുന്ന ഒരു സെഷനാണ്. എന്തെങ്കിലും വ്യുൽപ്പന്നം ചെയ്യുന്ന ഏക രീതികൾ സർവർ നിരസിക്കുന്നിടത്തോളം ക്ലയന്റ് വീണ്ടും ശ്രമിക്കുന്നത് അത് മാറ്റില്ല.

ഇതിൽ നിന്ന് ഉണ്ടാകുന്ന നിയമം ചെറുതാണ്: പ്രൊഫൈൽ MPPE ആവശ്യപ്പെടുന്നെങ്കിൽ, രീതി MS-CHAP-ന്റെ ഒരു രൂപമോ സർവർ കീകൾ തിരികെ നൽകുന്ന EAP രീതിയോ ആയിരിക്കണം. MS-CHAPv2 മാത്രം നിരസിക്കുന്നത് അത് നിർബന്ധമാക്കുന്നില്ല, കാരണം MS-CHAPv1-ഉം കീകൾ വ്യുൽപ്പന്നം ചെയ്യുന്നു, വെവ്വേറെ നിരസിച്ചില്ലെങ്കിൽ ലഭ്യമായി തുടരുന്നു; രണ്ടും നിരസിച്ചാൽ സാധാരണ CHAP-ഉം PAP-ഉം അവശേഷിക്കുന്നു, അവ ഒന്നും വ്യുൽപ്പന്നം ചെയ്യാതെ ആവശ്യകത നിറവേറ്റാനാകാത്തതാക്കുന്നു. ഇഷ്ടപ്പെടാത്തവ പട്ടികപ്പെടുത്തുന്നതിന് പകരം സ്വീകരിക്കുന്ന രീതി വ്യക്തമായി പേരിടുക. ക്ലയന്റ് കണക്റ്റ് ചെയ്യാൻ എൻക്രിപ്ഷൻ ആവശ്യകത ഉപേക്ഷിക്കുന്നത് നന്നാക്കലല്ല, തരംതാഴ്ത്തലാണ്.

ക്ലയന്റ് എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് സർവറിന്റെ ഓപ്ഷനുകൾ വായിക്കുക

ഈ പൊരുത്തക്കേടുകളിൽ മിക്കതും സർവറിൽ രണ്ട് ഫയലുകളിൽ കാണാം, അവ വായിക്കുന്നത് ക്ലയന്റ് പുനർനിർമ്മിക്കുന്നതിനേക്കാൾ വിലകുറവാണ്. Linux PPTP എൻഡ്പോയിന്റിൽ ബന്ധപ്പെട്ട ക്രമീകരണങ്ങൾ pptpd കൈമാറുന്ന pppd ഓപ്ഷൻ ഫയലിൽ കഴിയുന്നു. ക്ലയന്റ് സ്റ്റാറ്റസ് സ്ക്രീനിൽ നിന്നല്ല, സർവറിൽ ഇത് പ്രവർത്തിപ്പിക്കുക. സംരക്ഷണ മോഡ് ആവശ്യപ്പെടുന്ന, നിരസിക്കുന്ന അല്ലെങ്കിൽ പേരിടുന്ന വരികളിൽ നിന്ന് തുടങ്ങുക:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

ഔട്ട്പുട്ട് ഫ്ലാഗുകളുടെ പട്ടികയായല്ല, ഒരു കരാറായി വായിക്കുക. MPPE ആവശ്യപ്പെട്ടുകൊണ്ട് MS-CHAP-ന്റെ രണ്ട് രൂപങ്ങളും നിരസിക്കുന്ന വരി ഏത് ക്ലയന്റിനും നിറവേറ്റാനാകില്ല, MS-CHAP രീതിക്കുള്ള ആവശ്യകത ഇല്ലാത്തത് കീ നൽകാത്ത കൈമാറ്റങ്ങൾക്ക് വാതിൽ തുറന്നിടുന്നു. പിന്നീട് ആർക്കാണ് പ്രാമാണീകരണത്തിന് അനുമതി എന്ന് പരിശോധിക്കുക, അത് രഹസ്യ ഫയൽ തീരുമാനിക്കുന്നു:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് മൂന്ന് മൂല്യങ്ങൾ എഴുതുക: പുറം പ്രോട്ടോക്കോൾ, സർവർ ആവശ്യപ്പെടുന്ന പ്രാമാണീകരണ രീതി, സംരക്ഷണം നിർബന്ധമാണോ ഐച്ഛികമാണോ. ആ മൂന്നും തുടർന്നുള്ള ഓരോ തീരുമാനവും നിർണ്ണയിക്കുന്നു, ക്ലയന്റ് സംഭാഷണത്തിൽ നിന്ന് അവ ഊഹിക്കുന്നതാണ് പ്രൊഫൈൽ പകുതി കോൺഫിഗർ ചെയ്ത് നിൽക്കുന്ന വഴി. ജോലി ചെയ്യുമ്പോൾ ഫയൽ തുറന്നിടുക, അടുത്ത വിഭാഗത്തിന് അതേ മൂന്ന് മൂല്യങ്ങൾ വേണം.

PPP ഘട്ടം അനുസരിച്ച് പരാജയം കണ്ടെത്തുക

PPP പരാജയങ്ങൾ ഘട്ടങ്ങളായി റിപ്പോർട്ട് ചെയ്യുന്നു, ഏത് ഘട്ടം കരാറിന്റെ ഏത് വ്യവസ്ഥ തകർന്നു എന്ന് പറയുന്നു. ലിങ്ക് നിയന്ത്രണം ഒരിക്കലും വിടാത്ത ലിങ്കിന് എൻകാപ്സുലേഷൻ അല്ലെങ്കിൽ ചർച്ച പ്രശ്നമുണ്ട്, പ്രാമാണീകരിച്ച് പിന്നീട് മരിക്കുന്ന ലിങ്കിന് സാധാരണയായി നയ അല്ലെങ്കിൽ കീ പ്രശ്നമുണ്ട്. മുകളിൽ നിൽക്കുകയും ഒന്നും വഹിക്കാതിരിക്കുകയും ചെയ്യുന്ന ലിങ്ക് റൂട്ടിംഗിലേക്ക് കടന്നു, അത് മറ്റൊരു അന്വേഷണമാണ്.

ജേണൽ ഘട്ട വരികൾ സൂക്ഷിക്കുന്നു, അവ ഉയർന്ന ഡീബഗ് നിലയേക്കാൾ ഉപയോഗപ്രദമാണ്. PPP പ്രോസസുകളും സംരക്ഷണ സന്ദേശങ്ങളും ആവശ്യപ്പെടുക, പിന്നീട് എല്ലാറ്റിനും മുമ്പ് പ്രാമാണീകരണ ഫലം വായിക്കുക. അവസാന വരികൾ സാധാരണയായി നിരസിച്ച വ്യവസ്ഥ പേരിടുന്നു:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

ആ ഔട്ട്പുട്ടിൽ ആദ്യം പ്രാമാണീകരണ ഫലം, പിന്നീട് സംരക്ഷണം ആവശ്യപ്പെട്ടിരുന്നു പക്ഷേ ചർച്ച ചെയ്തിട്ടില്ല എന്ന പരാതി തിരയുക. രണ്ടാമത്തെ സന്ദേശം മുകളിലെ വൈരുദ്ധ്യത്തിന്റെ ഒപ്പാണ്, സർവർ കീ ഉത്പാദിപ്പിക്കാൻ കഴിയുന്ന ഏക രീതി നിരസിക്കുന്നിടത്തോളം എത്ര വീണ്ടും ശ്രമിച്ചാലും അത് മായ്ക്കുന്നില്ല. രണ്ട് കെണികൾ പേരിടാൻ യോഗ്യമാണ്: ഘട്ട വരികൾ വായിക്കാതെ ഡീബഗ് നില ഉയർത്തുന്നത് ബഹളം ഉണ്ടാക്കുന്നു, വെല്ലുവിളി മെറ്റീരിയലോ പാസ്വേഡുകളോ പിടിക്കുന്നത് കോൺഫിഗറേഷൻ ജോലിയെ ക്രെഡൻഷ്യൽ ചോർച്ചയാക്കി മാറ്റുന്നു. ഏതെങ്കിലും ഓപ്ഷൻ മാറ്റുന്നതിന് മുമ്പ് ആ ഘട്ടം രേഖപ്പെടുത്തുക.

പഴയ എൻഡ്പോയിന്റ് ഓഫ് ചെയ്യുന്നതിന് മുമ്പ് പുറത്തുകടക്കാൻ പദ്ധതിയിടുക

MPPE ചരിത്രപരമായ ഒരു ലിങ്ക് സംരക്ഷണ സംവിധാനമാണ്, അതിന്റെ സാന്നിധ്യം PPTP-യെ പുതിയ വിന്യാസത്തിന് വിവേകപൂർണ്ണമായ തിരഞ്ഞെടുപ്പാക്കുന്നില്ല. നിലവിലെ Microsoft മാർഗ്ഗനിർദ്ദേശം പുതിയ റിമോട്ട് ആക്സസ് വിന്യാസങ്ങൾക്ക് PPTP-യ്ക്കും മുൻകൂട്ടി പങ്കിട്ട കീയുള്ള L2TP/IPsec-നും എതിരായി ഇതിനകം ശുപാർശ ചെയ്യുന്നു. പഴയ എൻഡ്പോയിന്റ് ജീവനോടെ നിലനിർത്തുന്നത് നിലവിലുള്ള സേവനത്തെക്കുറിച്ചുള്ള തീരുമാനമാണ്, അടുത്തതിനുള്ള ടെംപ്ലേറ്റല്ല.

എൻഡ്പോയിന്റ് നിൽക്കേണ്ടിവന്നാൽ കരാർ എഴുതുക: പുറം പ്രോട്ടോക്കോൾ, ആവശ്യമായ പ്രാമാണീകരണ രീതി, നിർബന്ധിത സംരക്ഷണം, അത് ചർച്ച ചെയ്യുന്ന ക്ലയന്റ് പതിപ്പ്. അതിന് പോകാമെങ്കിൽ, പഴയ പ്രൊഫൈൽ തൊടുന്നതിന് മുമ്പ് പകരക്കാരന്റെ ഗേറ്റ്വേ ഐഡന്റിറ്റി, അതിന്റെ ക്ലയന്റ് പ്രാമാണീകരണം, ക്രെഡൻഷ്യലുകൾ കഴിയുന്ന സ്ഥലം എന്നിവ തിരഞ്ഞെടുക്കുക. പിന്നീട് റൂട്ടുകൾ, DNS, ഓരോ ഉപയോക്താവിനും പ്രവേശനാധികാരമുള്ള വിഭവങ്ങൾ എന്നിവ പദ്ധതിയിടുക. ഉദ്ദേശിച്ച ക്ലയന്റ് പ്രവർത്തിക്കുന്ന കണക്ഷനുമായല്ല, ഉടമയുടെ ആവശ്യകതകളുമായി സാധൂകരിക്കുക.

മനഃപൂർവമായ നിരസിക്കൽ നിരസിക്കലായി തുടരണം, പരീക്ഷ പാസാകാൻ സംരക്ഷണമില്ലാത്ത മോഡിലേക്ക് പിൻവാങ്ങുന്നത് നയ പരാജയത്തെ വെളിപ്പെടുത്തലാക്കി മാറ്റുന്നു. പൂർത്തിയായ അവസ്ഥ പിന്തുണയുള്ള, രേഖപ്പെടുത്തിയ ഒരു കരാറാണ്, ഒരു പഴയ കണക്ഷൻ വിജയിപ്പിക്കുന്ന ഏറ്റവും ചെറിയ മാറ്റക്കൂട്ടമല്ല. പകരക്കാരൻ അതേ പരിശോധനകൾ പാസാകുന്നതുവരെ പഴയ പ്രൊഫൈൽ അതിന്റെ സ്ഥാനത്ത്, ഉപയോഗിക്കാതെ, രേഖപ്പെടുത്തി വയ്ക്കുക.