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 යෙදවීමට හේතුවක් ලෙස නොව.