Ошибки записи 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 остаётся подозреваемым. Это момент вернуться к захвату, а не к хранилищу учётных данных.