L2TP ബന്ധിപ്പിക്കുന്നു പക്ഷേ PPP ചർച്ച പരാജയപ്പെടുന്നു: ഏത് ഘട്ടം?

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

ടണൽ ആദ്യ പാളി മാത്രം

L2TP IPsec-സംരക്ഷിത ടണലിനുള്ളിൽ PPP ഫ്രെയിമുകൾ കൊണ്ടുപോകുന്നു, അതായത് പാക്കറ്റ് റൂട്ട് ചെയ്യുന്നതിന് മുമ്പ് രണ്ട് സ്വതന്ത്ര ചർച്ചകൾ വിജയിക്കണം. പുറം ചർച്ച ഇരു അറ്റങ്ങളും കീകളിലും ഐഡന്റിറ്റികളിലും യോജിക്കുന്നു എന്ന് തെളിയിക്കുന്നു. ഉള്ളിലെ ചർച്ച ലിങ്ക് പാരാമീറ്ററുകൾ, ഉപയോക്താവ് പ്രാമാണീകരിക്കപ്പെടുമോ, ക്ലയന്റ് ഏത് വിലാസം സ്വീകരിക്കും എന്നിവ തീരുമാനിക്കുന്നു.

PPP-യ്ക്കുള്ളിലെ പരാജയം ഒരു സ്റ്റാറ്റസ് ലൈറ്റ് മാത്രം കാണിക്കുന്ന ഓരോ ക്ലയന്റിലും തകർന്ന ടണൽ പോലെ തോന്നുന്നു. അതിനെ ടണൽ പ്രശ്നമായി കാണുന്നത് കീകൾ വീണ്ടും ഉണ്ടാക്കുന്നതിനും സേവനങ്ങൾ പുനരാരംഭിക്കുന്നതിനും ഒടുവിൽ ഒരിക്കലും തെറ്റായിരുന്നിട്ടില്ലാത്ത പങ്കിട്ട രഹസ്യം മാറ്റിസ്ഥാപിക്കുന്നതിനും നയിക്കുന്നു. ഉപയോഗപ്രദമായ വ്യത്യാസം വിലകുറഞ്ഞതാണ്: പിയറുമായുള്ള കൈമാറ്റം പൂർത്തിയായി ക്ലയന്റ് ഉപയോക്തൃനാമ അഭ്യർത്ഥനയിലേക്കോ പ്രാമാണീകരണ ഘട്ടത്തിലേക്കോ കടന്നാൽ ടണൽ കുഴപ്പമില്ല. അതിനുശേഷമുള്ളതെല്ലാം PPP-യുടേതാണ്.

വിജയിച്ച അവസാന ഘട്ടം വായിക്കുക

ലോഗ് മുന്നോട്ട് നടന്ന് പൂർത്തിയാകാത്ത ആദ്യ ഘട്ടത്തിൽ നിർത്തുക. ആദ്യം LCP, പിന്നെ പ്രാമാണീകരണം, പിന്നെ IPv4 പാരാമീറ്ററുകൾക്കായി IPCP.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

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

ടിക്കറ്റിൽ ഘട്ടത്തിന്റെ പേരിനൊപ്പം ലോഗ് ഭാഗം സൂക്ഷിക്കുക. ഘട്ടത്തിന്റെ അതിർത്തിയില്ലാതെ ഒട്ടിച്ച വാൽ അടുത്ത വായനക്കാരനെ ഊഹിക്കാൻ ക്ഷണിക്കുന്നു, ഇവിടെ ഊഹിക്കുന്നത് ഒരു മണിക്കൂർ ചെലവാക്കുന്നു.

ക്ലയന്റും സെർവറും തമ്മിലുള്ള യോജിപ്പ്

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

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

വിലാസം പരിശോധിക്കുക, ലോഗിൻ അല്ല

പൂർത്തിയായ ലോഗിൻ ഉപയോഗയോഗ്യമായ സെഷനല്ല. IPCP ആന്തരിക വിലാസം ചർച്ച ചെയ്യുന്നു, തീർന്ന വിലാസ കൂട്ടമോ ക്ലയന്റിനെ നിരസിക്കുന്ന നയമോ ഇപ്പോഴും ബന്ധിപ്പിച്ച ടണലിനെ റൂട്ട് ചെയ്യാൻ ഒന്നുമില്ലാതെ വിടാം.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

ആദ്യം ആന്തരിക വിലാസം പരിശോധിക്കുക, പിന്നെ യഥാർത്ഥത്തിൽ വേണ്ട വിഭവത്തിന്റെ റൂട്ടും റിസോൾവറും. ആന്തരിക വിലാസം ഒരു വെബ്സൈറ്റ് റിപ്പോർട്ട് ചെയ്യുന്ന പൊതു എക്സിറ്റല്ല, രണ്ടും കൂട്ടിക്കലർത്തുന്നത് ഇല്ലാത്ത ഒരു ചോർച്ച തിരയാൻ ആളുകളെ അയയ്ക്കുന്നു. സ്വകാര്യ വിഭവം പേരിനാൽ പരീക്ഷിക്കുന്നതിന് മുമ്പ് വിലാസം കൊണ്ട് പരീക്ഷിക്കുക, DNS പരാജയം റൂട്ടിംഗ് പരാജയമായി തെറ്റിദ്ധരിക്കാതിരിക്കാൻ.

ഘട്ടം, രീതി, വിലാസം എന്നിവ ഒരു കുറിപ്പിൽ എഴുതി തീയതി ചേർക്കുക. അതേ അക്കൗണ്ട് ഒരു മാസത്തിനുശേഷം വീണ്ടും പരാജയപ്പെട്ടാൽ, ആ കുറിപ്പാണ് അഞ്ച് മിനിറ്റ് പരിശോധനയും പുതിയ അന്വേഷണവും തമ്മിലുള്ള വ്യത്യാസം. വ്യത്യസ്ത ഘട്ടങ്ങളിലെ പരാജയങ്ങൾ വ്യത്യസ്ത സംഭവങ്ങളാണ്, ക്ലയന്റ് ഒരു ഡയലോഗ് മാത്രം കാണിച്ചാലും.