Връзката се удостоверява, клиентът съобщава, че е свързан, и секунда по-късно журналът се затваря с прекратяване на 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 на нови места.

Подобни статии