Профілі PPTP, які наполягають, що пароль неправильний, кажуть дещо вужче, ніж звучить. Секрет перевіряється в самому кінці ланцюга, що починається з узгодження можливостей, тому будь-яка невідповідність раніше в цьому ланцюзі виявляється як помилка автентифікації. Тому скидання пароля, повторне введення чи перестворення профілю нічого не змінює. Спершу прочитайте узгодження, потім виберіть виправлення за тим, яку частину шляху ви контролюєте.

Чому секрет ніколи не перевіряється

Автентифікація PPP узгоджується: сервер пропонує методи, клієнт відповідає тим, що вміє, і обидві сторони домовляються про один ще до обміну будь-якими обліковими даними. Коли сервер пропонує лише EAP-PEAP, а pppd клієнта його не реалізує, розмова закінчується на етапі пропозиції. Сервер записує помилку автентифікації, бо це той етап, який не вдався, а не тому що пароль порівняли і визнали недостатнім.

Тому помилка однакова і для неправильного пароля, і для невідповідності методу. Лише журнал їх розрізняє, і тільки якщо клієнту дозволено бути докладним.

Читайте узгодження, а не останню помилку

Запустіть з'єднання на передньому плані з увімкненим налагодженням і читайте рядки автентифікації згори. Журнал називає запропонований метод, прийнятий метод і місце, де обмін зупинився. Профіль, який ніколи не виходить із CHAP чи MSCHAPv2, поки сервер очікує PEAP, — це проблема методу, а не облікових даних. Останній рядок цього журналу — те місце, де клієнт здався, а не те, де причина.

sudo pppd call provider debug nodetach

Збережіть цей вивід. Це також доказ, потрібний власникові мережі перед зміною політики сервера, і він вирішує питання, чи пароль взагалі брав участь.

Друга причина ховається у файлі секретів

Якщо журнал показує, що методи збігаються, подивіться на файл, який зберігає секрет. Переведення рядка або кінцевий пробіл, записані в поле пароля, надсилаються як частина пароля, тому сервер порівнює інший рядок, ніж ви ввели. У редакторі файл виглядає правильно, і саме тому це переживає стільки спроб.

sudo cat -A /etc/ppp/chap-secrets

Знак долара позначає кінець кожного рядка в цьому виводі. Поле пароля з чимось перед цим знаком або випадковий пробіл між полями треба переписати з лапками, які документує інструмент.

Виберіть виправлення за тим, кому належить сервер

Якщо сервер ваш, дозвіл MSCHAPv2 для цього облікового запису — найменша зміна, і вам варто записати, що ви свідомо прийняли слабший метод. Якщо він чужий, чесне виправлення — клієнт, що реалізує EAP-PEAP; латання pppd робить несумісність вашою проблемою обслуговування. Якщо вибір протоколу ще відкритий, PPTP — найслабша частина архітектури, і міграція зазвичай дешевша, ніж підтримувати пропатчений клієнт живим. Запишіть це рішення біля профілю, щоб наступна людина не відкрила його знову.

Хоч би який шлях ви обрали, після цього перевірте з другої машини в іншій мережі. Збережений профіль може й далі пропонувати старий метод і робити виправлений сервер схожим на зламаний. Потім приберіть налаштування налагодження, бо докладні журнали PPP на спільній робочій станції можуть записати більше, ніж ви хочете.

Схожі статті