PPTP-യിൽ LCP പീയർ അവസാനിപ്പിച്ചു: ആദ്യം MPPE പ്രവർത്തനക്ഷമമാക്കുക

ലിങ്ക് പ്രാമാണീകരണത്തിലൂടെ കടന്നുപോകുന്നു, ക്ലയന്റ് കണക്ട് ചെയ്തതായി റിപ്പോർട്ട് ചെയ്യുന്നു, ഒരു സെക്കൻഡിന് ശേഷം ലോഗ് LCP പീയർ അവസാനിപ്പിച്ചു എന്നതോടെ അടയുന്നു. ആ വരി GRE ടണലിനുള്ളിലെ PPP ചർച്ചയിൽ നിന്നാണ് വരുന്നത്, അതായത് ട്രാൻസ്പോർട്ട് ഇതിനകം പ്രവർത്തിച്ചിരുന്നു, ലിങ്ക് ഓപ്ഷനുകളിൽ രണ്ട് അറ്റങ്ങളും യോജിച്ചിരുന്നില്ല. ഇവിടെ പാസ്വേഡുകളും സർവർ വിലാസങ്ങളും സാധാരണയായി നിരപരാധികളാണ്. ആദ്യം താരതമ്യം ചെയ്യേണ്ടത് എൻക്രിപ്ഷൻ നയമാണ്, Linux-ൽ pppd-യുടെ പീയർ ഫയലാണ് ആദ്യം നോക്കേണ്ട സ്ഥലം.

LCP പരാജയം PPP ഘട്ടത്തെക്കുറിച്ച് എന്ത് പറയുന്നു

PPTP, PPP-യെ GRE-യ്ക്കുള്ളിൽ പൊതിയുന്നു: TCP 1723 കൺട്രോൾ കണക്ഷൻ കോള് സജ്ജമാക്കുന്നു, GRE പേലോഡ് വഹിക്കുന്നു, തുടർന്ന് LCP പ്രാമാണീകരണ പ്രോട്ടോക്കോൾ, കംപ്രഷൻ, MPPE തുടങ്ങിയ ഓപ്ഷനുകൾ ചർച്ച ചെയ്യുന്നു. ആവശ്യമായ ഓപ്ഷൻ അവരുടെ ഭാഗത്ത് സ്വീകാര്യമല്ലാത്തപ്പോൾ പീയർ LCP അവസാനിപ്പിക്കുന്നു. CHAP അല്ലെങ്കിൽ MSCHAPv2 കൈമാറ്റം പൂർത്തിയായി ഉടൻ LCP അവസാനിക്കുന്ന ലോഗ് നയത്തിന്റെ നിരാകരണമാണ്, എത്തിച്ചേരാനുള്ള പരാജയമല്ല. ടണൽ ചർച്ചയിൽ എത്തുന്നില്ലെങ്കിൽ, LCP വരി വായിക്കുന്നതിന് മുമ്പ് pppd-യും അതിന്റെ പ്ലഗിനും പരിശോധിക്കുക.

രണ്ട് മുൻവ്യവസ്ഥകൾ എളുപ്പം വിട്ടുപോകുന്നു. pppd ബൈനറി ഉണ്ടായിരിക്കണം, പീയർ ഫയലിൽ പേരിട്ട PPTP പ്ലഗിൻ ഇൻസ്റ്റാൾ ചെയ്തിരിക്കണം; പാക്കേജ് ഇല്ലെങ്കിൽ ഏതെങ്കിലും ഓപ്ഷൻ ചർച്ച ചെയ്യുന്നതിന് മുമ്പ് ഡയൽ അവസാനിക്കുന്നു.

MPPE ആവശ്യപ്പെടുന്ന ഭാഗത്ത് അത് പ്രവർത്തനക്ഷമമാക്കുക

യഥാർത്ഥ തീരുമാനം എൻക്രിപ്ഷൻ നയം ഏത് അറ്റത്തിനാണ് എന്നതാണ്. ക്ലയന്റിന് MPPE വാഗ്ദാനം ചെയ്യാം, ആവശ്യപ്പെടാം അല്ലെങ്കിൽ നിരാകരിക്കാം, സർവറും അതേ തിരഞ്ഞെടുപ്പ് നടത്തുന്നു. രണ്ടും ആവശ്യപ്പെട്ടാൽ ലിങ്ക് ഉയരുന്നു; ഒന്ന് ആവശ്യപ്പെട്ട് മറ്റൊന്ന് നിരാകരിച്ചാൽ LCP അവസാനിക്കുന്നു.

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

ഡയൽ ചെയ്യുന്നതിന് മുമ്പ് modprobe ppp_mppe ഉപയോഗിച്ച് മൊഡ്യൂൾ ലോഡ് ചെയ്യുക, കാരണം അതില്ലാതെ require-mppe-128 പരാജയപ്പെടുന്നു. Windows-ൽ തുല്യമായ നിയന്ത്രണം VPN എൻട്രിയുടെ സെക്യൂരിറ്റി ടാബാണ്, അവിടെ സർവർ നൽകുന്നത് സ്വീകരിക്കുന്നതിന് പകരം എൻക്രിപ്ഷൻ ആവശ്യപ്പെടാൻ ക്ലയന്റിനോട് പറയണം. സർവർ ഇപ്പോഴും LCP അവസാനിപ്പിക്കുന്നുവെങ്കിൽ, MPPE നിർബന്ധമാണോ ഐച്ഛികമാണോ നിഷ്ക്രിയമാണോ എന്ന് അതിന്റെ ഓപ്പറേറ്ററോട് ചോദിക്കുക, കാരണം സർവർ നിരാകരിക്കുന്ന സംരക്ഷണം ക്ലയന്റിന് ചർച്ച ചെയ്യാനാകില്ല. സന്ദേശം അപ്രത്യക്ഷമാകാൻ എൻക്രിപ്ഷൻ ഓഫ് ചെയ്യുന്നത് തെറ്റായ ദിശയാണ്: അത് ഈ പ്രോട്ടോക്കോളിനുള്ള ഏക സംരക്ഷണം നീക്കിക്കളയുന്നു.

എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് പ്രവർത്തിക്കുന്ന പീയർ ഫയൽ സേവ് ചെയ്യുക. തെറ്റായി ടൈപ്പ് ചെയ്ത require-mppe വരി അതേ പൊതുവായ LCP പരാജയം പുനരാവിഷ്കരിച്ച് നിങ്ങളെ തുടക്കത്തിലേക്ക് തിരികെ അയക്കുന്നു.

ആപ്ലെറ്റിന് പകരം pppd-യുടെ സ്വന്തം ലോഗ് വായിക്കുക

ഡെസ്ക്ടോപ്പ് ആപ്ലെറ്റുകൾ വിച്ഛേദനം കാണിക്കുകയും കാരണം മറയ്ക്കുകയും ചെയ്യുന്നു, അതിനാൽ ഒരു ശ്രമത്തെക്കുറിച്ചുള്ള ഡീമോണിന്റെ വിവരണം വായിക്കുക. systemd സിസ്റ്റങ്ങളിൽ സന്ദേശം ജേണലിലേക്ക് പോകുന്നു; പഴയ ക്രമീകരണങ്ങൾ പരമ്പരാഗത ലോഗ് ഫയലുകളിൽ എഴുതുന്നു.

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

ഒരു ദിവസത്തെ വീണ്ടും കണക്ഷനുകൾക്ക് പകരം ഒരു ഡയലിന് ചുറ്റുമുള്ള ജാലകത്തിൽ തിരയുക, അപ്പോൾ നിരാകരിച്ച ഓപ്ഷൻ എളുപ്പം കാണാം. pppd സാധാരണയായി ഓപ്ഷന്റെ പേരും പീയറിന്റെ മറുപടിയും പറയുന്നു, അത് സ്വന്തം നിർദ്ദേശം മാറ്റണോ സർവർ ഭാഗത്തോട് ആവശ്യം അയച്ചുകൊടുക്കണോ എന്ന് അറിയിക്കുന്നു. ശ്രമങ്ങൾ സമയമുദ്രകളോടെ സൂക്ഷിക്കുക, കാരണം ഏത് വരികൾ ഏത് കോളിന്റേതാണെന്ന് അറിയാതെ രണ്ട് ലോഗുകൾ താരതമ്യം ചെയ്യുന്നത് ഉപയോഗപ്രദമല്ല. LCP കൈമാറ്റം തന്നെ കാണുന്നില്ലെങ്കിൽ, തകരാർ ശൃംഖലയിൽ നേരത്തെയാണ്, MPPE സംശയിക്കപ്പെടുന്നവനല്ല.

വീണ്ടും കണക്ഷനുകളിൽ തിരുത്തൽ നിലനിർത്തുക: ഹൂക്ക് നാമങ്ങളും MTU-വും

ലിങ്ക് നിലനിന്നാൽ, വീണ്ടും കണക്ഷനെ അത് അതിജീവിക്കുമോ എന്ന് രണ്ട് വിശദാംശങ്ങൾ തീരുമാനിക്കുന്നു. ഹൂക്കുകൾ /etc/ppp/ip-up.d, /etc/network/if-up.d എന്നിവയിലാണ്, രണ്ട് ഡയറക്ടറികളും run-parts പ്രോസസ്സ് ചെയ്യുന്നു, അതിന്റെ ഫയൽനാമ ഫിൽട്ടർ ഡോട്ട് ഉള്ളതെല്ലാം നിരാകരിക്കുന്നു. അതിനാൽ set-pptp.sh എന്ന സ്ക്രിപ്റ്റ് ഒഴിവാക്കപ്പെടുന്നു, set-pptp പ്രവർത്തിപ്പിക്കുന്നു. സ്ക്രിപ്റ്റിന്റെ ഉള്ളടക്കം ഡീബഗ് ചെയ്യുന്നതിന് മുമ്പ് പേര് പരിശോധിക്കുക, തുടർന്ന് അതേ ഹൂക്കിനുള്ളിൽ നിന്ന് ചെറിയ MTU സജ്ജമാക്കുക, അങ്ങനെ ഓരോ പുതിയ ppp ഇന്റർഫേസും കൈയിൽ കമാൻഡ് ഇല്ലാതെ അത് പാരമ്പര്യമായി സ്വീകരിക്കും.

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

സെഷൻ ബോധപൂർവം അവസാനിപ്പിക്കാൻ പ്രോസസ് നാമങ്ങൾ പാറ്റേൺ ചെയ്യുന്നതിന് പകരം pppd രേഖപ്പെടുത്തിയ pid ലക്ഷ്യമിടുക, കാരണം ppp ഉള്ളതെല്ലാം കൊല്ലുന്നത് ബന്ധമില്ലാത്ത ലിങ്കുകളും വലിച്ചുകീറും. PPTP കാലഹരണപ്പെട്ടതും MS-CHAPv2 ദുർബലവുമാണ്, അതിനാൽ ഈ പരിശോധനകളെ പ്രവർത്തിക്കേണ്ട ഒരു ലിങ്കിന്റെ പരിപാലനമായി കാണുക, എവിടെയെങ്കിലും പുതുതായി PPTP വിന്യസിക്കാനുള്ള കാരണമായി അല്ല.