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 где-то ещё.