L2TP/IPsec-сервер на Debian 12: пошаговая установка

MAATRIX

L2TP/IPsec — не самый быстрый и не самый модный протокол, но у него есть одно решающее преимущество: клиент встроен в Windows, macOS, iOS и Android без установки стороннего софта. Если нужно подключить сотрудника с корпоративным ноутбуком, где нельзя ставить приложения, или бабушкин iPhone — L2TP/IPsec поднимается за 15 минут и подключается штатными средствами системы. Ниже — полный цикл установки на Debian 12: strongSwan для IPsec, xl2tpd для L2TP, PSK-аутентификация и настройка клиентов.

Что понадобится и как работает связка

L2TP/IPsec — это не один протокол, а два, работающих в связке:

• IPsec (через strongSwan) шифрует канал и обеспечивает базовую защиту трафика — это транспортный уровень.
• L2TP (через xl2tpd) поверх уже зашифрованного IPsec-туннеля создаёт виртуальный сетевой интерфейс (PPP), выдаёт клиенту IP-адрес и маршрутизирует трафик.

Схема аутентификации двухуровневая: сначала клиент и сервер согласовывают IPsec-туннель по общему ключу (PSK — pre-shared key), а затем внутри этого туннеля PPP-сессия проверяет логин и пароль пользователя. То есть для подключения нужно знать и PSK, и учётные данные — это не супернадёжно (PSK общий на всех, в отличие от сертификатов WireGuard), но для быстрого доступа с готовых клиентов вполне достаточно.

Для установки понадобится:

• Debian 12 (Bookworm) с правами root или sudo.
• Публичный IP-адрес сервера (без NAT перед сервером).
• Открытые порты: UDP 500, UDP 4500 (IPsec/NAT-T), UDP 1701 (L2TP, обычно не нужен наружу отдельно — работает внутри IPsec).

Если сервера ещё нет — под L2TP/IPsec подходит любой VPS с белым IP и ядром, поддерживающим модули IPsec (у современных Debian-образов это из коробки).

Подготовка системы

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

apt update && apt upgrade -y

Включите IPv4 forwarding на постоянной основе:

cat >> /etc/sysctl.conf <<EOF
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
EOF
sysctl -p

Проверьте, что модуль l2tp_ppp доступен в ядре — на Debian 12 он обычно уже встроен:

modprobe l2tp_ppp
lsmod | grep l2tp

Если строка l2tp_ppp не появилась — потребуется пересобрать ядро с этой опцией, но на стандартных VPS-образах это редкость: модуль есть почти всегда.

Установка strongSwan и xl2tpd

Ставим оба пакета одной командой:

apt install -y strongswan strongswan-pki libcharon-extra-plugins xl2tpd

На Debian 12 в репозиториях strongSwan версии 5.9.x, xl2tpd — 1.3.18. Это заметно новее, чем в Ubuntu 22.04 (strongSwan 5.9.5), но конфигурационный синтаксис не менялся, так что все параметры ниже работают одинаково на обеих системах.

Проверьте версии после установки:

strongswan version
xl2tpd -v

Настройка strongSwan (IPsec)

Основной конфиг — /etc/ipsec.conf. Замените текущее содержимое:

config setup
    charondebug="ike 1, knl 1, cfg 0"
    uniqueids=no

conn %default
    keyexchange=ikev1
    ike=aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
    esp=aes256-sha1,aes128-sha1,3des-sha1!

conn L2TP-PSK
    keyexchange=ikev1
    left=%defaultroute
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any
    type=transport
    authby=secret
    auto=add
    dpddelay=30
    dpdtimeout=120
    dpdaction=clear
    rekey=no
    forceencaps=yes

Строка forceencaps=yes заставляет сервер всегда заворачивать IPsec в UDP-пакеты на 4500 порту — это спасает клиентов, сидящих за NAT (то есть почти всех мобильных пользователей).

Ключ PSK хранится в /etc/ipsec.secrets. Укажите публичный IP сервера и придумайте длинный ключ:

: PSK "ваш-длинный-случайный-ключ-минимум-20-символов"

Сгенерировать случайный ключ можно так:

openssl rand -base64 24

Перезапустите strongSwan и проверьте статус:

systemctl restart strongswan-starter
systemctl status strongswan-starter
ipsec statusall

Если сервис не стартует — почти всегда причина в синтаксической опечатке ipsec.conf (лишний пробел, неверный отступ) или в занятом порту 500/4500 другим процессом.

Настройка xl2tpd (L2TP)

Основной конфиг — /etc/xl2tpd/xl2tpd.conf:

[global]
port = 1701

[lns default]
ip range = 192.168.42.10-192.168.42.250
local ip = 192.168.42.1
require chap = yes
refuse pap = yes
require authentication = yes
name = L2TPServer
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

Диапазон 192.168.42.0/24 — это внутренняя подсеть только для VPN-клиентов, она не пересекается с сетью самого сервера.

Файл /etc/ppp/options.xl2tpd задаёт параметры PPP-сессии:

require-mschap-v2
ms-dns 1.1.1.1
ms-dns 8.8.8.8
asyncmap 0
auth
crtscts
lock
hide-password
modem
name l2tpd
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4

DNS-серверы (ms-dns) — те, что получит клиент. Можно указать любые публичные резолверы или свой DNS-сервер, если он настроен на сервере.

Учётные данные пользователей хранятся в /etc/ppp/chap-secrets:

# client        server  secret          IP addresses
vpnuser1        l2tpd   "СложныйПароль1"        *
vpnuser2        l2tpd   "СложныйПароль2"        *

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

Запустите xl2tpd:

systemctl restart xl2tpd
systemctl enable xl2tpd
systemctl status xl2tpd

Firewall и NAT

Клиентам L2TP-подсети нужен выход в интернет через NAT, а серверу — открытые порты для IPsec. Если вы используете iptables напрямую:

iptables -t nat -A POSTROUTING -s 192.168.42.0/24 -o eth0 -j MASQUERADE
iptables -A FORWARD -s 192.168.42.0/24 -j ACCEPT
iptables -A FORWARD -d 192.168.42.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 500 -j ACCEPT
iptables -A INPUT -p udp --dport 4500 -j ACCEPT
iptables -A INPUT -p udp --dport 1701 -j ACCEPT

Замените eth0 на реальное имя внешнего интерфейса — уточнить его можно командой ip a. Правила нужно сохранить, иначе после перезагрузки они исчезнут:

apt install -y iptables-persistent
netfilter-persistent save

Если на сервере стоит UFW, логика та же, но синтаксис отличается — про это подробно разобрано в статье про настройку UFW на VPS; там же — как не отрезать себе SSH-доступ по невнимательности при написании правил.

Отдельно проверьте, что порт 1701 (L2TP) не торчит наружу, если вы используете форс-инкапсуляцию — трафик L2TP всегда идёт внутри UDP 4500, а прямой доступ к 1701 снаружи не нужен и его можно закрыть, оставив только для локального интерфейса.

Настройка клиентов

Windows 10/11: Параметры → Сеть и интернет → VPN → Добавить VPN-подключение. Тип VPN — "L2TP/IPsec с общим ключом", в качестве ключа — тот самый PSK из ipsec.secrets, логин/пароль — из chap-secrets. Отдельно нужно поправить реестр, если сервер за NAT (у вас — нет, публичный IP), иначе Windows требует:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 2

Это применяется на клиентской машине, если Windows отказывается поднимать туннель с ошибкой 809.

macOS: Системные настройки → Сеть → добавить (+) → VPN → L2TP через IPsec. Поля те же: адрес сервера, PSK, логин/пароль.

iOS: Настройки → VPN → Добавить конфигурацию VPN → тип L2TP. Заполняете сервер, аккаунт, пароль, общий ключ.

Android: Настройки → Сеть → VPN → добавить VPN, тип L2TP/IPsec PSK. Некоторые версии Android (начиная с 12) требуют стороннее приложение (strongSwan из Google Play), так как встроенный клиент был урезан — учитывайте это заранее, если целевая аудитория — Android-пользователи.

Диагностика типичных проблем

Основной источник информации при отладке — два лога параллельно:

journalctl -u strongswan-starter -f
journalctl -u xl2tpd -f

Подключаетесь клиентом и смотрите, на каком именно этапе обрывается процесс — Phase 1 IKE, Phase 2 ESP или уже PPP-аутентификация. Это сразу сужает круг подозреваемых.

Ограничения протокола, о которых стоит знать честно

L2TP/IPsec — рабочий вариант для совместимости, но не для максимальной безопасности или скорости:

• PSK общий на всех клиентов — если один сотрудник уволился и ключ не сменили, теоретически он может подключаться, зная логин/пароль (которые вы, конечно, тоже отзовёте, но сам факт общего секрета — слабое место по сравнению с индивидуальными ключами WireGuard).
• Двойная инкапсуляция (IPsec + PPP) даёт заметный оверхед — на слабых каналах ощутима просадка скорости относительно WireGuard.
• Протокол легко детектируется DPI по сигнатурам UDP 500/4500 — там, где важно маскировать VPN-трафик, L2TP/IPsec не подходит.

Если приоритет — производительность и современная криптография, а не совместимость со встроенными клиентами, посмотрите на сравнение WireGuard и OpenVPN — для новых проектов это чаще более разумный выбор. L2TP/IPsec имеет смысл именно там, где нельзя ставить сторонний клиент: корпоративные политики, урезанные права на устройстве, встроенная поддержка в ОС.

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