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 повідомлення потрапляє до 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 десь іще.