Почему один 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 и ресурсы, к которым каждый пользователь имеет право доступа. Проверяйте предполагаемый клиент по требованиям владельца, а не по работающему соединению.

Преднамеренный отказ должен оставаться отказом, потому что возврат к незащищённому режиму ради прохождения теста превращает отказ политики в уязвимость. Готовое состояние — это поддерживаемый, документированный договор, а не наименьший набор изменений, который позволяет одному старому соединению заработать. Оставьте старый профиль на месте, неиспользуемым и документированным, пока замена не пройдёт те же проверки.