Почему PPTP и L2TP/IPsec останавливаются до запроса имени пользователя?

Отсутствие запроса имени пользователя — диагностический подарок: PPP ещё не запустился, поэтому учётная запись, пароль и доменная политика ещё не запрашивались. В соединении PPTP или L2TP/IPsec клиент запрашивает учётные данные только после того, как туннель существует и сервер начал сеанс PPP. Всё, что может отказать до этого момента, — транспорт, обмен ключами или настройка туннеля, а это куда меньшая область, чем «VPN сломан».

Отсутствующий запрос сужает сбой до трёх этапов

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

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

Первый этап: протокол, который межсетевой экран тихо отбрасывает

PPTP нужен TCP 1723 для канала управления и протокол IP 47 для пути данных, и эти двое путешествуют отдельно. Многие сети пропускают 1723 и отбрасывают протокол 47, что даёт туннель, который договаривается и затем не переносит вообще ничего. Маршрутизатору с NAT тоже нужен проход с поддержкой GRE, а путь доступа только через IPv6 не может нести PPTP ни при какой конфигурации.

L2TP поверх IPsec расходует порт 500 на IKE и порт 4500 на обход NAT, затем заворачивает сам трафик L2TP в 1701, а ESP несёт защищённую нагрузку, как только ассоциация существует. Разрешите два управляющих порта, но не ESP, и вы получите ровно тот симптом из заголовка: видимый прогресс, затем мёртвый клиент до любого диалога учётных данных. Проверка с точки доступа телефона — дешёвый способ отделить проблему клиента от проблемы пути.

Второй этап: ключ, который не ключ, предложение, которое не предлагается

Несовпадающий предварительно общий ключ отказывает быстро и тихо, и обычный вариант — ключ, который выглядит правильным на экране, но несёт вставленный перенос строки или пробел в конце. На клиенте Linux диалог не обязательно является источником истины: плагин L2TP в NetworkManager держит секреты в файлах под /etc/ipsec.d/, и более старый файл для отдельного подключения, который /etc/ipsec.secrets всё ещё включает, будет использован вместо только что введённого. Скопируйте этот файл в безопасное место, уберите его из пути включения, а затем введите ключ заново вручную.

Другая половина этого этапа — предложение. Обе стороны должны договориться об одном и том же наборе алгоритмов фазы 1 — шифрование, целостность и группа Diffie-Hellman — и о подходящих преобразованиях ESP для фазы 2, иначе ассоциация не образуется вовсе. Шлюз, предлагающий только 3DES, SHA1 и MODP1024, откажет клиенту, настроенному на более сильные алгоритмы, и его журнал назовёт отклонённое преобразование. Журнал назовёт несоответствие, если вы прочитаете его, а не перезапустите службу снова. Вместо копирования строки алгоритмов из ветки форума спросите шлюз, о каких преобразованиях он действительно будет договариваться: ike-scan, направленный на его адрес, возвращает преобразования, о которых он будет договариваться. Если единственное предложение — криптография, которую ваша политика больше не допускает, исправление относится к шлюзу, а не к понижению клиента.

В Windows ключ и метод аутентификации живут в профиле VPN, и несоответствие проявляется до запроса учётных данных, а не после. Там, где получатель — Windows Server, убедитесь, что роль удалённого доступа установлена, сертификат соответствует имени, к которому подключаются клиенты, и ни один фильтр портов не уже перечисленных выше протоколов.

Третий этап: туннель есть, а PPP не запускается

Когда IKE завершён, а запрос так и не появляется, смотрите на демон туннеля, а не на межсетевой экран. L2TP нужен кто-то слушающий на UDP 1701 — xl2tpd или kl2tpd в Linux, служба удалённого доступа в Windows — а установленная, но остановленная служба со стороны клиента выглядит точно как отброшенный пакет. Проверьте слушателя, прежде чем снова открывать правила, которые вы уже проверили. Затем PPP должен договориться, и первый обмен LCP — это место, куда обычно садится тихий отказ.

Одна ловушка на этом этапе вовсе не сетевая неисправность: Windows разрешает только одно подключение заданного типа VPN одновременно, поэтому вторая попытка возвращает ошибку 937, «другое подключение этого типа используется». Это локальное правило, и обойти его можно другим устройством, другим типом туннеля или совместным использованием единственного существующего подключения.

Читайте журнал в порядке этапов, а не гадайте

Остановите клиент, запустите его снова и читайте компоненты в том порядке, в каком они пишут журнал. То есть сначала демон IPsec — strongSwan или Libreswan, и ipsec --version скажет какой — затем демон L2TP, затем pppd. Какой бы компонент ни написал последним перед сбоем, он отмечает этап для расследования, потому что всё, что идёт после него в последовательности, вообще не работало.

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