Почему L2TP/IPsec нужен UDP 1701 помимо IPsec

Межсетевые экраны, которые разрешают IKE и ESP, но не UDP 1701, ломают соединения L2TP так, что это выглядит как проблема с учётными данными. Причина в том, что L2TP — второй протокол, который идёт внутри первого. IPsec переносит и проверяет обмен, а L2TP ведёт собственный туннель поверх UDP 1701, который локальный стек всё равно должен доставить. Знание того, где появляется каждый заголовок, объясняет, какому устройству какое правило нужно.

Два протокола, два набора портов

Соединение L2TP/IPsec использует IKE на UDP 500, прохождение NAT на UDP 4500 там, где есть трансляция, и ESP как IP-протокол 50 там, где её нет. Сам L2TP — туннельный протокол на UDP 1701, и он работает после того, как IPsec аутентифицировал партнёра. Две половины отказывают по-разному, и строки журнала, сообщающие о них, приходят из разных компонентов. Набор правил, покрывающий только первую половину, даёт соединение, которое договаривается и затем умирает на этапе туннеля.

Номера портов описывают транспортные конечные точки, а ESP вообще не порт. Поэтому интерфейс межсетевого экрана, предлагающий только правила TCP и UDP, не может выразить полную политику IPsec. Протокол 50 должен быть разрешён как протокол, и правило, упоминающее только UDP, никогда с ним не совпадёт.

Обёртка объясняет порт

В сети соединение L2TP/IPsec обычно показывает IKE на 500 и инкапсулированный ESP на 4500. Заголовок UDP 1701 находится внутри защищённой полезной нагрузки, поэтому перехват на внешнем интерфейсе его не показывает. Локальный хост всё равно должен доставить эту датаграмму демону L2TP, и доставка происходит после декапсуляции. Поэтому правило 1701 относится к межсетевому экрану самой конечной точки, даже когда ни одно промежуточное устройство никогда не видит порт.

Порядок обработки объясняет большую часть путаницы. Если стек применяет политику IPsec до фильтра хоста, декапсулированный пакет L2TP сопоставляется как UDP 1701; если порядок обратный, набор правил видит внешние порты. Оба поведения встречаются на практике, поэтому один и тот же набор правил выглядит работающим на одной платформе и отказывает на другой.

Проверяйте путь по порядку

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

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

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

Чего не может показать сканирование портов

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

Вместо этого проверьте настоящим клиентом и прочитайте, до какого этапа он доходит. Если соединение договаривается и затем застревает, подозреваемый — демон L2TP или локальный фильтр; если оно вообще не договаривается, виноваты внешние порты. Это единственное разделение снимает большую часть догадок о том, какое правило добавить, а расслоение протоколов делает это предсказуемым, а не загадочным.