இணைப்பு அங்கீகாரத்தைக் கடக்கிறது, கிளையண்ட் இணைந்ததாகத் தெரிவிக்கிறது, ஒரு வினாடிக்குப் பிறகு பதிவு 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-ஐ நிலைநிறுத்துவதற்கான காரணமாக அல்ல.

தொடர்புடைய கட்டுரைகள்