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 на ново место.