L2TP/IPsec не работает: отделите IPsec, аутентификацию туннеля или вход PPP

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

Три этапа аутентификации, три разные личности

IPsec доказывает, кому принадлежат конечные точки, используя предварительно разделённый ключ или сертификат. Эта личность принадлежит машинам или шлюзам и никогда — человеку за клавиатурой. Когда партнёры не могут договориться на этом этапе, не передаётся ни один пакет L2TP.

Управляющее соединение L2TP может добавить второй, отдельный обмен запрос-ответ, которым управляет общий секрет, обязательный для обеих сторон.

RFC 2661 делает эту аутентификацию управляющего соединения необязательной, что объясняет, почему одна и та же ошибка даёт разные симптомы на двух серверах. Развёртывание, которое никогда не настраивало секрет туннеля, полностью пропускает этап; то, которое настроило его только на одной стороне, терпит неудачу ещё до того, как PPP будет предложен. Затем PPP аутентифицирует пользователя по PAP, CHAP или MSCHAPv2 и передаёт имя хранилищу учётных записей, которое может быть локальным, в chap-secrets или в RADIUS. Неверный пароль в этот момент всё равно оставляет вас с работающим туннелем и неудачным сеансом.

Прочитайте точку остановки, прежде чем менять конфигурацию

Начните с ipsec --version, чтобы понять, принадлежит ли вывод состояния strongSwan или Libreswan. Затем читайте журнал сервера, а не окно клиента, потому что сервер записывает, какой этап отказал.

Одна строка обычно решает заявку: жалоба на IKE или предложения — это первый этап, сообщение об управляющем соединении — второй, а отказ метода PPP или учётной записи — третий. Скопируйте эту строку в заявку вместе с отметкой времени. Догадки на стороне клиента тратят единственное доказательство, которое у вас уже есть.

Держите ключевой материал и пароли вне этой вставки; имя этапа направляет работу, а утекший предварительно разделённый ключ открывает заявку заново с худшими последствиями.

Первый этап: есть ли у IPsec ассоциация?

Запустите ipsec statusall на strongSwan или ipsec whack --status на Libreswan и поищите установленную дочернюю ассоциацию с ненулевыми счётчиками. ip xfrm state показывает представление ядра на обоих. Установленная пара SA с растущими счётчиками означает, что первый этап завершён и можно двигаться дальше.

Полное отсутствие ассоциации указывает на адрес партнёра, набор предложений или предварительно разделённый ключ, а иногда на устройство, которое перезаписывает UDP 500, но отбрасывает UDP 4500. Ассоциация, которая устанавливается и затем исчезает через несколько секунд, обычно означает несовпадение времени жизни между сторонами, а не проблему с учётными данными. Проверьте, перечисляют ли обе стороны одни и те же предложения шифрования и хеширования, прежде чем что-то перепечатывать. Если нет, ни один ключ никогда не заработает.

Остановитесь, пока ассоциация отсутствует. Правка параметров PPP в этот момент ничего не меняет и скрывает настоящую неисправность от следующего человека.

Второй этап: аутентифицировалось ли управляющее соединение L2TP?

Когда IPsec поднят, следите за демоном L2TP: управляющее соединение должно достичь установленного состояния, иначе PPP не начнётся. Отказ на управляющем соединении означает, что секрет туннеля различается между сторонами или одна сторона требует секрет, который другая никогда не отправляет. Клиенты часто показывают одно поле с меткой shared secret, и обычно оно относится к IPsec, а не к L2TP. Его заполнение не настраивает секрет туннеля, а очистка не отключает его.

Если ни одна из сторон не настроила секрет туннеля, пропустите этот этап и рассматривайте сбой управляющего соединения как проблему доступности. Убедитесь, что UDP 1701 доходит до демона и обе стороны согласны насчёт одной и той же инкапсуляции. Правило межсетевого экрана, написанное для одного из этих двух условий, — частая причина соединения, которое открывается наполовину.

Только сеанс, который начинает согласование PPP, действительно прошёл этап туннеля.

Третий этап: PPP отклоняет учётную запись?

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

На сервере Linux проверьте файл параметров, который демон передаёт PPP, обычно /etc/ppp/options.xl2tpd, и подтвердите, какие методы принимаются и где разрешаются учётные записи. Имя, которое есть в RADIUS, но отсутствует в локальном файле секретов, сбой чисто и выглядит как неверный пароль. Затем проверьте, предлагает ли клиент метод, который сервер принимает, а не более сильный, согласование которого сервер отклоняет. Смена предварительно разделённого ключа ради починки этого этапа тратит полдня и ничего не меняет.

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