L2TP/IPsec или PPTP: почему в 2026 не стоит использовать PPTP

MAATRIX

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

Почему PPTP всё ещё живёт в старых инструкциях

PPTP (Point-to-Point Tunneling Protocol) разработан Microsoft ещё в середине 90-х и встроен в Windows начиная с 95 OSR2. Отсюда и его живучесть: клиент есть в каждой версии Windows, macOS до недавнего времени, в старых прошивках роутеров и в мобильных ОС без установки стороннего софта. Настройка сервера занимает пять минут — один пакет pptpd, один конфиг с логином и паролем, и туннель поднят.

Именно эта простота и делает PPTP популярным героем мануалов, которые писались десять с лишним лет назад и с тех пор просто копируются из статьи в статью без ревизии. Автор такого текста часто даже не упоминает, что с 2012 года протокол считается непригодным для защиты чувствительного трафика — потому что сам об этом не знает или не считает нужным предупредить.

Второй фактор — низкие требования к ресурсам. PPTP почти не нагружает CPU, потому что использует относительно слабое шифрование MPPE (Microsoft Point-to-Point Encryption) на базе RC4. На встраиваемых устройствах с процессором 90-х годов производительности это ощутимый плюс — только цена за него неприемлема с точки зрения безопасности.

Что именно сломано в PPTP: MS-CHAPv2 и MPPE

У PPTP два независимых слабых места, и оба фатальны для протокола, который позиционируется как средство защиты трафика.

Аутентификация MS-CHAPv2. В 2012 году исследователь Moxie Marlinspike публично показал, что для протокола аутентификации MS-CHAPv2 задача перебора эквивалентна взлому одного DES-ключа — а это вычислимо на арендованном оборудовании за разумное время, а не за годы. Был выпущен инструмент chapcrack, который извлекает хендшейк MS-CHAPv2 из перехваченного трафика и превращает задачу в готовый запрос к сервисам восстановления DES-ключей. С тех пор появились и офлайн-инструменты вроде asleap, которые атакуют тот же хендшейк при наличии словаря или достаточных вычислительных мощностей. Точное время взлома зависит от оборудования атакующего и с годами только сокращается — но сам факт, что MS-CHAPv2 сводится к вскрытию одного DES-ключа, никуда не делся и не может быть исправлен патчем на стороне сервера.

Шифрование MPPE. Даже если аутентификация устояла, сам трафик шифруется потоковым шифром RC4 с ключом, зависящим от MS-CHAPv2-хендшейка. RC4 официально считается небезопасным и исключён из современных TLS-реализаций именно из-за статистических слабостей потока. MPPE вдобавок не даёт forward secrecy: если ключевой материал одной сессии скомпрометирован (а он выводится из того же взламываемого MS-CHAPv2), под угрозой оказывается конкретное соединение, но принципиальная схема одинаково уязвима для всех сессий на этом сервере.

Отдельная головная боль PPTP — GRE (протокол 47), который туннель использует для передачи данных отдельно от управляющего TCP-соединения на порту 1723. GRE плохо проходит через NAT и часто блокируется файрволами провайдеров и корпоративных сетей, потому что не является ни TCP, ни UDP — многие NAT-реализации просто не умеют транслировать GRE-сессии для нескольких клиентов одновременно. На практике это означает нестабильные соединения даже там, где криптография вас почему-то устраивает.

L2TP/IPsec: как это работает и почему безопаснее

L2TP/IPsec — это не один протокол, а связка двух независимых слоёв, и в этом главное отличие от PPTP. IPsec (обычно в режиме ESP с IKEv1 или IKEv2 для согласования ключей) отвечает за шифрование и аутентификацию канала между клиентом и сервером на сетевом уровне. L2TP поверх уже зашифрованного IPsec-туннеля просто инкапсулирует PPP-кадры — он не отвечает за безопасность, потому что она уже обеспечена нижним слоем.

Практический эффект: даже если у L2TP или PPP есть исторические слабости, они не имеют значения, потому что весь трафик, включая сам процесс аутентификации PPP, уже находится внутри шифрованного IPsec-туннеля. Это принципиально другая модель по сравнению с PPTP, где MS-CHAPv2 одновременно и аутентифицирует пользователя, и участвует в выводе ключа шифрования — то есть одна уязвимость ломает обе функции сразу.

IPsec в связке L2TP/IPsec с предустановленным ключом (PSK) обычно использует AES вместо RC4, а для согласования ключей — Diffie-Hellman группы, которые дают некоторую форму forward secrecy на уровне IKE-сессии (в зависимости от выбранной группы и реализации). Это не делает L2TP/IPsec эталоном современной криптографии — протокол остаётся тяжеловеснее и капризнее, чем WireGuard или актуальные редакции OpenVPN, — но по сравнению с PPTP это переход из категории «взламывается публично доступными инструментами» в категорию «требует серьёзных ресурсов и, как правило, компрометации самого PSK».

Порты L2TP/IPsec тоже устроены иначе: UDP 500 (IKE), UDP 4500 (NAT-Traversal) и UDP 1701 (L2TP). Все три — обычный UDP, который куда лучше проходит через NAT и файрволы, чем GRE у PPTP. Это не решает проблему DPI-блокировок — фиксированные порты по-прежнему легко фильтруются на уровне провайдера, — но по крайней мере устраняет случайные обрывы из-за неправильной трансляции GRE.

Быстрый переход с PPTP на L2TP/IPsec

Миграция не требует смены операционной системы сервера — оба протокола прекрасно живут на одной и той же Ubuntu-машине, просто с разными демонами.

Если сейчас у вас поднят pptpd, план такой:

1. Остановите и удалите PPTP-сервер, чтобы не оставлять уязвимую точку входа открытой:

systemctl stop pptpd
apt purge -y pptpd

1. Поставьте strongSwan (реализация IPsec) и xl2tpd (реализация L2TP):

apt update
apt install -y strongswan xl2tpd

1. Настройте PSK и параметры IPsec в /etc/ipsec.conf и /etc/ipsec.secrets, затем L2TP в /etc/xl2tpd/xl2tpd.conf и PPP-опции в /etc/ppp/options.xl2tpd. Подробный конфиг с разбором каждой директивы — в отдельной пошаговой статье про L2TP/IPsec на Ubuntu 24.04; если у вас другой дистрибутив, аналогичные шаги описаны для AlmaLinux 9 и Debian 12.

1. Откройте на файрволе новые порты и закройте старые:

ufw allow 500/udp
ufw allow 4500/udp
ufw allow 1701/udp
ufw delete allow 1723/tcp

1. На клиентах пересоздайте подключение как L2TP/IPsec PSK вместо PPTP — в Windows, macOS и Android это делается штатными сетевыми настройками, без установки дополнительного софта, то есть ровно с тем же уровнем удобства, к которому вы привыкли на PPTP.

Учётные записи пользователей (CHAP-секреты в /etc/ppp/chap-secrets) в большинстве случаев можно перенести без изменений — формат файла общий для PPTP и L2TP, потому что оба используют PPP на верхнем уровне. Единственное, что стоит сделать заново, — это сгенерировать новый PSK-ключ, а не переиспользовать что-то, что раньше «было под рукой».

Сравнение протоколов

Если вы выбираете протокол с нуля, а не мигрируете со старого PPTP-сервера, честный совет — посмотреть сначала на WireGuard: он проще в настройке, быстрее по производительности и современнее по криптографии, чем и L2TP/IPsec, и PPTP. L2TP/IPsec остаётся оправданным выбором только там, где важна поддержка «из коробки» без установки клиентского софта — корпоративные ноутбуки с ограничением на установку приложений, старые Mikrotik и Keenetic, часть NAS-устройств.

Что делать, если L2TP/IPsec блокируют провайдеры

Фиксированные порты UDP 500/4500/1701 — не проблема на большинстве сетей, но в средах с активной DPI-фильтрацией их блокируют так же уверенно, как GRE у PPTP. Признак — IKE-хендшейк не завершается или обрывается сразу после установления (в логах strongSwan это видно как повторные попытки IKE_SA без перехода в established).

Если блокировка подтвердилась, у вас три пути. Первый — сменить сервер на локацию, где фильтрация мягче: для VPN и обхода блокировок стоит сравнить сервер в России, в США и в Великобритании — правила фильтрации входящего и исходящего трафика заметно различаются по юрисдикциям. Второй — перейти на протокол, который умеет маскироваться под обычный HTTPS-трафик поверх порта 443, то есть OpenVPN в TCP-режиме. Третий, самый радикальный, — WireGuard с обфускацией через дополнительный слой (например, туннелирование через Shadowsocks или обёртку удаётся настроить не в одну команду, поэтому это отдельная тема, а не быстрый фикс).

Важно понимать: сама по себе смена протокола не гарантирует обхода блокировки — это вопрос конкретной сети и конкретного DPI-решения провайдера, и результат стоит проверять на практике, а не полагаться на общие обещания.

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