Чому один PPP CHAP не може виконати вимогу MPPE

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

Усередині одного з'єднання PPTP відбуваються два узгодження

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

Простий CHAP — це обмін запит-відповідь із RFC 1994, побудований на спільному секреті й ні на чому більше. MS-CHAPv2 — інший обмін, з іншими повідомленнями та іншим результатом, стандартизований у RFC 2759. Спільне слово в двох назвах — єдине, що вони мають спільного на дроті. Жодна назва не каже, що виробляє обмін, і саме це єдина важлива частина.

Тому опція, позначена просто CHAP, неоднозначна в старому профілі. Коли сервер хоче MS-CHAPv2, а клієнт пропонує простий CHAP, керування з'єднанням усе ще може завершитися, і пароль усе ще може бути прийнятий. Збій приходить пізніше, коли сервер намагається вивести ключі захисту з обміну, який нічого не створив.

Узгодьте потрібний метод із ключами, які він може створити

Ключі MPPE не є властивістю PPP взагалі. Для родини Microsoft CHAP виведення задано в RFC 3079, і воно бере як вхід результат обміну MS-CHAP, а не спільний секрет. Методи EAP досягають того самого місця іншим шляхом, причому сервер автентифікації повертає ключі як атрибути MS-MPPE-Recv-Key і MS-MPPE-Send-Key. Простий CHAP не з'являється на жодному з двох шляхів, і це вся причина існування цієї невідповідності.

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

Звідси випливає коротке правило: якщо профіль вимагає MPPE, метод має бути варіантом MS-CHAP або методом EAP, ключі якого сервер повертає. Відхилення лише MS-CHAPv2 цього не забезпечує, бо MS-CHAPv1 теж виводить ключі й залишається доступним, якщо його не відхилити окремо; відхилення обох залишає простий CHAP і PAP, які нічого не виводять і роблять вимогу нездійсненною. Назвіть прийнятий метод явно замість переліку тих, що вам не подобаються. Відмова від вимоги шифрування, щоб клієнт підключився, — це зниження, а не ремонт.

Прочитайте параметри сервера, перш ніж редагувати клієнт

Більшість цих невідповідностей видно на сервері у двох файлах, і прочитати їх дешевше, ніж перезібрати клієнт. На кінцевій точці PPTP у Linux потрібні налаштування живуть у файлі параметрів pppd, який передає pptpd. Запускайте його на сервері, а не з екрана стану клієнта. Почніть із рядків, які вимагають, відхиляють або називають режим захисту:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

Читайте вивід як договір, а не як список прапорців. Рядок, який вимагає MPPE і водночас відхиляє обидва варіанти MS-CHAP, не може виконати жоден клієнт, а відсутність вимоги до методу MS-CHAP залишає двері відчиненими для обмінів, які не дають ключів. Потім перевірте, кому взагалі дозволена автентифікація, що вирішує файл секретів:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

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

Знайдіть збій за фазою PPP

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

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

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

У цьому виводі спершу шукайте результат автентифікації, а потім скаргу на те, що захист вимагався, але не був узгоджений. Друге повідомлення — підпис описаної вище суперечності, і жодна кількість повторних спроб його не прибирає, поки сервер відхиляє єдиний метод, здатний створити ключі. Варто назвати дві пастки: підвищення рівня налагодження без читання рядків фаз створює шум, а перехоплення матеріалу запиту або паролів перетворює завдання налаштування на витік облікових даних. Запишіть цю фазу, перш ніж змінювати будь-який параметр.

Сплануйте вихід, перш ніж стару кінцеву точку вимкнуть

MPPE — історичний механізм захисту з'єднання, і його наявність не робить PPTP розумним вибором для нового розгортання. Поточні настанови Microsoft уже радять проти PPTP і проти L2TP/IPsec із заздалегідь спільним ключем для нових розгортань віддаленого доступу. Підтримувати стару кінцеву точку живою — це рішення про наявну послугу, а не шаблон для наступної.

Коли кінцева точка має залишитися, запишіть договір: зовнішній протокол, потрібний метод автентифікації, обов'язковий захист і версія клієнта, яка це узгоджує. Коли вона може піти, виберіть ідентичність шлюзу заміни, її автентифікацію клієнта та місце, де житимуть облікові дані, перш ніж торкатися старого профілю. Потім сплануйте маршрути, DNS і ресурси, до яких кожен користувач має право доступу. Перевіряйте передбачуваний клієнт за вимогами власника, а не за робочим з'єднанням.

Навмисна відмова має залишатися відмовою, бо повернення до незахищеного режиму, щоб тест пройшов, перетворює збій політики на вразливість. Готовий стан — це підтримуваний, задокументований договір, а не найменший набір змін, який дає змогу одному старому з'єднанню спрацювати. Залиште старий профіль на місці, невикористаним і задокументованим, доки заміна не пройде ті самі перевірки.