Какой этап VPN не сработал: IPsec, управление L2TP или аутентификация PPP

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

Ответьте на четыре вопроса по порядку

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

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

Когда у вас есть только скриншот пользователя, опирайтесь на самое дешёвое разделение: неверный предварительно разделяемый ключ и xl2tpd, который никогда не отвечает, дают одинаковый текст в диалоге Windows, но одному нужен секрет, изменённый на обоих концах, а другому — запущенный демон или правило брандмауэра на самом сервере. Устройство посередине не может отбросить внутренний 1701 после того, как IPsec в транспортном режиме его обернул, поэтому не ищите фильтр пути, которого нет.

Чем на самом деле владеет каждый слой

IPsec защищает пакеты между двумя узлами; L2TP несёт сеанс PPP внутри этого защищённого пути, поэтому RFC 3193 предписывает транспортный режим, а не собственный туннель. Метка клиента говорит L2TP, поэтому туннель и вход ощущаются одним механизмом. Это не так: управляющее соединение L2TP аутентифицирует концы туннеля там, где развёртывание это включает, а PPP отдельно аутентифицирует пользователя через CHAP, PAP или MS-CHAPv2 согласно политике сервера.

Это разделение объясняет два секрета, которые люди постоянно путают. Предварительно разделяемый ключ аутентифицирует узлы IPsec. Имя пользователя и пароль идентифицируют пользователя для PPP. Повторный ввод общего секрета Windows в профиле, который аутентифицируется сертификатами, ничего не меняет на сбойном этапе, а правка пароля PPP не может дать отсутствующий защищённый канал. Та же сдержанность относится к проверке подлинности: не отключайте подлинность узла или проверку сертификата, чтобы получить туннель, потому что тогда соединяется путь, а не узел.

Аутентификация тоже не конец PPP. После того как пользователь принят, IPCP согласует адрес клиента и параметры DNS и WINS, которые сервер готов выдать. Клиент может пройти CHAP или MS-CHAPv2 и всё равно остаться без адреса, а это сбой внутри PPP, а не проблема маршрутизации. Обычный L2TP без IPsec остаётся действительным и незащищённым, поэтому успешное подключение никогда не доказывает, что трафик защищён; проверяйте, что требует сервер, а не метку клиента.

Решайте по первому отсутствующему этапу

Читайте таблицу по первому отсутствующему пункту, слева направо. Правый столбец — единственная работа, которая имеет смысл в этот момент; всё левее уже доказано, а повторная проверка сжигает окно простоя, не добавляя информации.

Три строки заслуживают предупреждения. Строка 1701 — это место, куда обычно попадают клиенты Windows за NAT: ассоциация завершается, затем ничего не приходит, и причина — инкапсуляция, а не плохой пароль. Строка IPCP — та, которую ошибочно читают как проблему маршрута, потому что Windows заворачивает отсутствующий адрес в ошибку 720, а значок в трее лишь говорит, что подключение не удалось; этот сбой находится после аутентификации и до маршрутизации. Последняя строка вовсе не сбой IPsec, хотя значок говорит «отключено».

Команды, которые разделяют слои

На сервере Linux со strongSwan swanctl --list-sas перечисляет установленные ассоциации с подлинностью узла, а ipsec statusall охватывает более старые хосты strongSwan и libreswan. Ниже ip xfrm state показывает фактические ассоциации ядра, а ss -lunp | grep 1701 доказывает, где привязан xl2tpd. Запустите xl2tpd -D на переднем плане, чтобы увидеть управляющие соединения и вызовы, и включите отладку pppd в /etc/ppp/options.xl2tpd, чтобы увидеть предложенный метод и ответ.

Когда журналы показывают успешную аутентификацию, следующий вопрос — завершился ли IPCP. Проверьте, есть ли у ip range в разделе [lns default] файла /etc/xl2tpd/xl2tpd.conf ещё свободные адреса и действительно ли /etc/ppp/options.xl2tpd несёт ms-dns и ms-wins, если клиент их ожидает. Исчерпанный пул и отсутствующий параметр DNS выглядят на проводе по-разному: первый оставляет клиента без адреса и с 720, второй даёт адрес, но без резолвера, поэтому имена не работают, а ping по сырым адресам идёт. Ни то ни другое не исправляется повторным вводом пароля.

На клиенте плагин L2TP в NetworkManager пишет беседу pppd в журнал, поэтому journalctl -u NetworkManager -b обычно отделяет туннель поднят, аутентификация отклонена от туннеля нет вовсе. В Windows Get-VpnConnection сообщает реальные параметры аутентификации профиля, а события RasClient в разделе Application просмотрщика событий называют сбойный компонент. Когда диалог слишком неясен, включите netsh ras set tracing * enable.

Записи требуют одной осторожности. В транспортном режиме IPsec внутренний UDP 1701 зашифрован, поэтому запись на внешнем интерфейсе показывает ESP или UDP 4500 при NAT-T и вовсе никакого L2TP. Отсутствие 1701 в записи ожидаемо и не является доказательством закрытого порта; следите, движутся ли счётчики ESP или 4500.

NAT, MTU и маршруты: где стек вводит вас в заблуждение

NAT ломает допущения ещё до того, как что-либо аутентифицировано. ESP — собственный протокол IP, поэтому транслирующее устройство отбрасывает его, если узлы не инкапсулируют; именно это обеспечивает UDP 4500. На сервере Windows, который сам стоит за домашним маршрутизатором или облачным шлюзом NAT, этап IPsec срывается с ошибкой 789, пока AssumeUDPEncapsulationContextOnSendRule не будет установлен в 2 под ключом PolicyAgent и машина не перезагрузится, и сбой остаётся неотличим от закрытого порта. Клиенты за NAT проще: при публичном адресе сервера NAT-T на UDP 4500 их несёт, и это значение не участвует.

Когда PPP поднят, MTU с чёрной дырой имитирует мёртвый туннель: мелкие пакеты проходят, рукопожатие TLS или загрузка страницы зависают, а клиент может по-прежнему показывать «подключено». Снизьте MTU интерфейса или зажмите MSS на шлюзе, прежде чем винить сервер. Маршрутизация раздельного туннеля — другой самозванец; подсеть, отправленная с неверной маской, оставляет туннель здоровым, а одно приложение недоступным. Частное имя хоста добавляет свой шаг: если запрос уходит через локальный резолвер, имя не разрешается до проверки любого маршрута.

Контрольный список, прежде чем трогать учётные данные

Пройдите список по порядку и остановитесь на первом сбойном пункте. Каждый шаг дешёв, и каждый исключает целый класс правок.

1. Подтвердите, что ассоциация есть на обоих концах, сопоставленная по подлинности узла, а не по метке «подключено».
2. Подтвердите, что UDP 1701 доходит до xl2tpd; ассоциация без вызова — это ваш сбой.
3. Прочитайте вердикт PPP и, если он аутентифицировал, результат IPCP, прежде чем считать пароль неверным.
4. Только теперь введите учётные данные заново в формате, которого ждёт сервер, потому что префикс домена меняет учётную запись.
5. Если всё ещё не работает, снимите оба конца с выровненными метками времени и сравните этап за этапом.

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