LCP спынены суразмоўцам на PPTP: спачатку ўключыце MPPE
Спыненне LCP суразмоўцам на злучэнні PPTP — гэта неадпаведнасць палітыкі PPP. Параўнайце патрабаванні MPPE, прачытайце журнал pppd і праверце назвы хукаў, перш чым кранаць уліковыя даныя.
Злучэнне праходзіць аўтэнтыфікацыю, кліент паведамляе пра падключэнне, і праз секунду журнал закрываецца запісам пра спыненне LCP суразмоўцам. Гэты радок паходзіць з перамоў PPP унутры тунеля GRE, значыць транспарт ужо працаваў, а два бакі разышліся ў поглядах на параметры злучэння. Паролі і адрасы сервера тут звычайна не вінаватыя. Палітыка шыфравання — першае, што трэба параўнаць, а ў Linux першае месца, куды варта паглядзець, — гэта файл суразмоўцы pppd.
Што збой LCP кажа пра этап PPP
PPTP заварочвае PPP у GRE: кіруючае злучэнне TCP 1723 устанаўлівае выклік, GRE нясе карысную нагрузку, а затым LCP дамаўляецца пра такія параметры, як пратакол аўтэнтыфікацыі, сцісканне і MPPE. Суразмоўца спыняе LCP, калі патрабаваны параметр непрымальны на яго баку. Журнал, дзе абмен CHAP або MSCHAPv2 завяршаецца, а LCP спыняецца адразу пасля, — гэта адмова па палітыцы, а не збой дасяжнасці. Калі тунель наогул не даходзіць да перамоў, праверце pppd і яго плагін, перш чым чытаць радок LCP.
Дзве перадумовы лёгка прапусціць. Бінарны файл 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 дзесьці новае.