L2TP/IPsec: почему протокол считают устаревшим

L2TP попадается почти каждому, кто хоть раз открывал раздел VPN в настройках операционной системы: он есть в списке типов подключения на Windows, macOS, iOS и в части сборок Android — и стоит там рядом с IKEv2, без пояснений, чем они отличаются. Отсюда и вопросы: это протокол шифрования или нет, почему его всегда пишут через дробь с IPsec и что имеют в виду, когда называют устаревшим.

Разберём по частям: что делает L2TP сам по себе, зачем связке второй слой, какие порты ей нужны и что из этого следует, где протокол до сих пор на месте — и почему «устаревший» здесь означает не «сломанный», а «с узкой оставшейся нишей».

L2TP сам по себе не шифрует

Полное название — Layer 2 Tunneling Protocol, и слово «туннелирование» в нём единственное, которое описывает функцию. Протокол появился как объединение двух более ранних разработок, PPTP от Microsoft и L2F от Cisco, и решает одну задачу: переносит кадры канального уровня через произвольную IP-сеть. Внутри такого туннеля живёт обычная PPP-сессия со своей авторизацией по имени и паролю.

Чего в L2TP нет — конфиденциальности и проверки целостности. Полезная нагрузка идёт в открытом виде, и это не упущение, а разделение обязанностей: в самом стандарте предполагается, что защиту обеспечит отдельный механизм. Поэтому в чистом виде L2TP как VPN не используют, и в интерфейсах он почти всегда подписан связкой — «L2TP/IPsec», «L2TP over IPsec», «L2TP/IPSec PSK».

Два слоя: кто за что отвечает

Связка собирается снизу вверх, и порядок здесь важен.

IKE согласует параметры IPsec. Устройство и сервер договариваются о ключах и алгоритмах. В классической реализации L2TP/IPsec это IKEv1 — исторически именно он, а не более новый IKEv2.
IPsec в транспортном режиме поднимает защищённый канал. Шифрование и контроль целостности — его работа, обычно через ESP.
Внутри этого канала строится туннель L2TP. Он даёт то, чего у транспортного режима IPsec нет: точку подключения, выдачу адреса, сессию с логином.
Внутри L2TP работает PPP, и уже внутри PPP едет ваш собственный IP-пакет.

Отсюда главная структурная претензия: слоёв на один больше необходимого. Пакет упакован в PPP, PPP — в L2TP, L2TP — в ESP, ESP — снова в IP. Каждый слой добавляет заголовок, и накладные расходы заметны: меньше полезных данных в пакете, ниже эффективный MTU, больше работы процессору. Именно из-за MTU появляется классическая жалоба «сайты открываются, а большие файлы обрываются». Ту же задачу без прослойки L2TP и PPP решает более новая связка — что такое IKEv2/IPsec и когда он нужен.

Фиксированные порты и что из них следует

Связке нужны три номера, и все три известны заранее.

UDP 500 — IKE, согласование параметров IPsec. Без него соединение не начнётся вообще.
UDP 1701 — собственно L2TP. В штатной схеме он работает уже внутри шифрованного канала.
UDP 4500 — тот же обмен и те же данные, но обёрнутые для прохождения через NAT.

Плюс сам ESP, который не UDP и не TCP, а отдельный протокол IP-уровня с номером 50. Портов у него нет, и для сетевого оборудования это отдельный тип трафика, который нужно пропускать явным правилом.

Следствий два. Первое административное: чтобы связка поднялась, на маршрутизаторе и файрволе должны быть открыты все нужные порты плюс ESP — типовая ошибка настройки состоит в том, что открывают 500 и забывают про 4500. Второе касается заметности: набор портов постоянный, поэтому такой трафик классифицируется по одному номеру порта, без разбора содержимого. Протоколы, которые ходят по 443 и внешне похожи на обычный HTTPS, ведут себя в этом смысле иначе; общая картина собрана в обзоре какие протоколы VPN актуальны в 2026 году.

Почему NAT — отдельная проблема

Домашний роутер и мобильный оператор прячут за одним внешним адресом много внутренних, и различают устройства по номерам портов. ESP такой возможности не даёт: портов у него нет, и когда за одним адресом оказываются два клиента с туннелями к одному серверу, оборудованию нечем их развести. Второй компонент IPsec, AH, ломается под NAT ещё принципиальнее — он подписывает в том числе заголовок IP, который NAT по своей задаче меняет, и подпись после этого не сходится.

Лечится это механизмом NAT-T: пакеты ESP заворачиваются в UDP 4500, и у них появляются порты, за которыми NAT умеет следить. Механизм рабочий, но со своими условиями. Поддержка нужна на обоих концах. К уже длинной цепочке добавляется ещё один заголовок. И исторически многие реализации плохо переносили ситуации «сервер за NAT» и «несколько клиентов за одним NAT» — часть систем требовала для этого отдельной правки настроек, не предусмотренной обычным интерфейсом. В эпоху, когда мобильные операторы массово выдают абонентам общий внешний адрес, это не редкий сценарий, а обычный.

PSK или сертификаты

IPsec в этой связке проверяет не пользователя, а сторону соединения, и делает это одним из двух способов. Общий ключ (PSK) — одна строка, одинаковая для всех, кто подключается к серверу. Сертификат — отдельная идентичность для каждого устройства.

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

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

Где L2TP до сих пор уместен

У протокола осталось одно устойчивое преимущество, и оно не техническое: он встроен. Клиент L2TP/IPsec есть в Windows, macOS, iOS и во многих сборках Android — устанавливать нечего, доступ добавляется как запись в настройках системы. Отсюда сценарии, где он всё ещё разумный выбор:

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

Как именно заводится такая запись на четырёх системах и что нужно получить от сервиса заранее — в отдельной инструкции: как добавить VPN вручную, без установки приложения.

Рядом с IKEv2 и WireGuard

Короткое сопоставление, без пересказа отдельных статей. IKEv2 занимает ровно ту же нишу «встроен в систему, приложение не нужно», но делает работу на слой короче и переживает переход между Wi-Fi и мобильной сетью без разрыва — при выборе внутри системных настроек это чаще всего решающий аргумент. WireGuard и OpenVPN в системном списке типов не появляются вообще: им нужен свой клиент, и сравнивать их корректнее друг с другом — OpenVPN или WireGuard: сравнение протоколов.

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

Чего VPN здесь не делает

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

Не скрывает сам факт использования VPN. Постоянные порты и характерный обмен на старте видны как VPN-соединение, даже когда содержимое зашифровано.
Не делает вас анонимным. Сервер знает ваш настоящий адрес, а сайты, где вы вошли в аккаунт, узнают вас по логину и cookie.
Не защищает от фишинга и вредоносных файлов. Туннель передаёт содержимое как есть, независимо от протокола.
Не отменяет вопрос доверия к серверу. Шифрование заканчивается на узле, а чей это узел и что он записывает — свойство сервиса, а не протокола.
Не исправляет ошибки настройки. Утечка DNS-запросов или IPv6 мимо туннеля от выбора между L2TP и IKEv2 не зависит.
Не гарантирует, что соединение поднимется. Если нужные порты в сети не проходят, протокол не подберёт себе замену: перебором занимается приложение, а не системный профиль.

Частые вопросы

L2TP/IPsec безопасен или нет?

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

Почему сайты открываются, а большие файлы не грузятся?

Типичный признак проблем с MTU: цепочка заголовков в L2TP/IPsec длинная, и пакеты предельного размера через туннель не проходят. Лечится это настройкой размера пакета на стороне клиента или сервера, а не сменой локации.

Что выбрать, если в настройках системы есть и L2TP, и IKEv2?

При прочих равных — IKEv2: та же встроенная поддержка, на слой меньше накладных расходов и заметно лучше поведение при переключении между сетями. L2TP имеет смысл, когда сервис или оборудование другого варианта не предлагает.

Вывод

L2TP — не плохой протокол, а протокол с узкой оставшейся нишей. Он честно делает то, для чего создан: переносит канальный уровень через IP-сеть, оставляя шифрование IPsec. Проблема в том, что за прошедшие годы появились варианты, которым для того же результата не нужен дополнительный слой инкапсуляции, не нужны три фиксированных порта и не нужны обходные механизмы для NAT. Поэтому L2TP/IPsec остаётся там, где решает совместимость: встроен в систему, понятен старому оборудованию, настраивается без установки приложений. Везде, где выбор свободен, разумнее взять что-то более современное — и ровно этот смысл стоит вкладывать в слово «устаревший».