LCP прекинут од партнера на PPTP-у: прво омогућите MPPE

Веза се аутентификује, клијент пријављује повезаност и секунду касније дневник се затвара записом 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 системима порука одлази у journal; старија подешавања пишу у традиционалне лог датотеке.

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

Да намерно завршите сесију, циљајте pid који је pppd забележио уместо да подударате имена процеса, јер убијање свега што садржи ppp руши и неповезане везе. PPTP је застарео и MS-CHAPv2 је слаб, зато ове провере третирајте као одржавање везе која мора да настави да ради, а не као разлог да распоредите PPTP на новом месту.