L2TP подключается, но согласование PPP не проходит: какая фаза?

Туннель IPsec устанавливается, клиент показывает защищённого партнёра, и затем соединение обрывается до того, как что-либо достигнет частной подсети. Этот разрыв — PPP, выполняющий свою собственную работу: параметры звена, аутентификация пользователя и назначение адреса происходят все после того, как зашифрованный туннель существует. Ничто в успешном обмене первой фазы не выдаёт пароль или внутренний адрес. Читайте фазы по порядку, и сбой обычно называет себя сам.

Туннель — это только первый уровень

L2TP переносит кадры PPP внутри туннеля, защищённого IPsec, а значит, для маршрутизации пакета должны состояться два независимых согласования. Внешнее доказывает, что обе стороны согласны насчёт ключей и идентичностей. Внутреннее решает параметры звена, аутентифицируется ли пользователь и какой адрес получает клиент.

Сбой внутри PPP выглядит как сломанный туннель в каждом клиенте, показывающем единственный индикатор состояния. Если считать это проблемой туннеля, дело доходит до перегенерации ключей, перезапуска служб и в конце до замены общего секрета, который никогда не был неверным. Полезное различие дёшево: если обмен с партнёром завершился и клиент перешёл к запросу имени пользователя или к этапу аутентификации, туннель в порядке. Всё после этой точки принадлежит PPP.

Прочитайте последнюю фазу, которая завершилась успешно

Пройдите журнал вперёд и остановитесь на первой фазе, которая не завершилась. Сначала идёт LCP, затем аутентификация, затем IPCP для параметров IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Тайм-аут LCP означает, что две стороны так и не договорились об основных параметрах звена, а это не неверный пароль, а несовпадение профиля или заблокированный внутренний протокол. Явный отказ в аутентификации — обратный случай: звено поднялось, и одна сторона отвергла учётные данные. Тайм-аут IPCP после успешной аутентификации указывает на пулы адресов или политику сервера. У каждого из них другой владелец и другое исправление, поэтому фаза важнее итогового текста ошибки.

Храните выдержку из журнала вместе с названием фазы в заявке. Вставленный хвост без границы фазы приглашает следующего читателя гадать, а догадки здесь стоят часа.

Согласие между клиентом и сервером

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

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

Проверяйте адрес, а не вход

Завершённый вход — ещё не пригодный сеанс. IPCP согласует внутренний адрес, и исчерпанный пул или политика, отклоняющая клиента, всё ещё могут оставить подключённый туннель без чего-либо для маршрутизации.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Сначала проверьте внутренний адрес, затем маршрут и резолвер для ресурса, который вам действительно нужен. Внутренний адрес — это не публичный выход, о котором сообщает сайт, и путаница между ними отправляет людей искать утечку, которой нет. Проверяйте частный ресурс по адресу раньше, чем по имени, чтобы сбой DNS не приняли за сбой маршрутизации.

Запишите фазу, метод и адрес в одну заметку и поставьте дату. Если тот же аккаунт снова откажет через месяц, эта заметка — разница между пятиминутной проверкой и новым расследованием. Сбои на разных фазах — разные инциденты, даже если клиент показывает единственное окно.