Помилки запису GRE на pptpd — не проблема пароля

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

Два повідомлення, дві різні несправності

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

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

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

Протокол 47 — не порт 47

PPTP використовує TCP 1723 для встановлення виклику й GRE для перенесення корисного навантаження. GRE — це IP-протокол 47, а не номер порту, тому правило брандмауера, яке відкриває порт 47, не дозволяє нічого корисного.

Маршрутизатору на шляху потрібна функція PPTP passthrough або явний дозвіл GRE. Без цього рукостискання TCP завершується, а тунель так і не переносить пакет, що дає саме описану вище помилку читання. Правила для порту 47 у брандмауері — найчастіший спосіб марно витратити день у цьому протоколі.

Спостерігайте обидва напрямки одночасно на сервері, замість того щоб гадати, яка сторона відкидає трафік: tcpdump -ni any port 1723 or proto gre.

Якщо 1723 показує встановлення виклику, а GRE мовчить, блокування розташоване вище хоста. Якщо GRE надходить, а демон усе ще зазнає невдачі, проблема локальна, і параметри — наступне місце для перевірки.

Дозвольте GRE там, де хост справді пересилає

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

Додайте input-правило для пакетів, адресованих самому серверу, бо ланцюжок forward їх не бачить. Потім подивіться на лічильники правила до й після спроби з'єднання, що скаже вам, чи пакети взагалі надходять.

Зробіть правило постійним через службу брандмауера дистрибутива, а не запускайте його знову після кожного перезавантаження. На хості з nftables зіставте ip protocol gre і в ланцюжку input, і в ланцюжку forward.

Переконайтеся, що модуль ppp_generic теж завантажено, і перевірте, чи не відкидає відстеження з'єднань зворотний напрямок. І те й те дає збої, які виглядають як проблема брандмауера і нею не є. Відсутній модуль ядра виглядає точно як заблокований протокол, доки ви не перевірите.

Узгодьте параметри з клієнтом, який у вас справді є

Виправлення з іншого звіту міститься в /etc/ppp/pptpd-options, де рецепт відмовляється від PAP, CHAP і MSCHAP, коментує відповідні рядки require і зберігає MPPE зі станом. Той рецепт писався для одного набору клієнтів, і сліпе копіювання ламає звичайний випадок. Читайте рядки відмови як твердження про те, які клієнти були в автора, а не як рекомендацію.

Клієнту Windows зазвичай потрібен MS-CHAPv2 з MPPE-128. Збережіть ці вимоги й видаліть лише ті параметри, які клієнт справді не може узгодити.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

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

Прочитайте номер помилки клієнта

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

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

Коли вхід успішний, а трафік не рухається, GRE залишається підозрюваним. Це момент повернутися до захоплення, а не до сховища облікових даних.