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

MAATRIX

L2TP/IPsec — не самый быстрый и не самый современный протокол, но поддержка у него встроена почти во все операционные системы и роутеры без установки стороннего софта. Если нужно подключить старый Mikrotik или корпоративный ноутбук с урезанными правами, связка с общим ключом часто оказывается единственным вариантом. Разберём установку strongSwan + xl2tpd на Ubuntu 24.04 по шагам, с проверкой результата и разбором граблей — а их тут больше, чем у любого другого протокола.

Что получится в итоге

Сервер, принимающий подключения от штатных VPN-клиентов Windows, macOS, Android и от роутеров вроде Mikrotik и Keenetic — без установки на них софта. Конкретно:

• charon (strongSwan) слушает UDP 500 и 4500 и шифрует трафик на уровне IPsec.
• xl2tpd поверх шифрованного канала поднимает туннель и раздаёт адреса из пула 10.10.10.0/24.
• Двухуровневая аутентификация: PSK на уровне IPsec плюс логин с паролем на PPP.
• NAT: трафик клиента выходит в интернет с публичного IP сервера, сайты видят его страну.
• Свои DNS-серверы по туннелю, чтобы имена не резолвились через провайдера.
• Автозапуск обеих служб после перезагрузки.

Чего не получится: скорости и простоты WireGuard, устойчивости к DPI, лёгкой масштабируемости. Это размен ради совместимости — если она не нужна, ставьте WireGuard.

Словарь: что означают все эти слова

Когда L2TP/IPsec ещё актуален

Если есть выбор, для личного VPN лучше взять WireGuard — он проще, быстрее и современнее по криптографии. L2TP оправдан в трёх случаях. Первый — встроенные клиенты без установки приложений: Windows, macOS и Android поднимают L2TP/IPsec PSK штатными средствами, без прав администратора, что критично на рабочих ноутбуках с запретом на установку софта (со стороны пользователя это разобрано в статье про встроенный L2TP/IPsec-клиент Windows 11). Второй — старые роутеры и NAS: Mikrotik, Keenetic, Synology и QNAP поддерживают протокол «из коробки». Третий — встраиваемые устройства с зашитым клиентом под L2TP или PPTP; последний использовать не стоит вовсе, и почему PPTP не вариант разобрано отдельно.

Минусы проговорим прямо. Два слоя — вдвое больше точек отказа. Производительность ниже из-за инкапсуляции пакета в пакет и обработки в пространстве пользователя; насколько ниже — зависит от CPU и канала, измеряйте у себя. С обходом блокировок тоже хуже: фиксированные порты легко фильтруются DPI, и для этой задачи смотрите в сторону WireGuard или OpenVPN.

Подготовка сервера

Понадобится Ubuntu 24.04 с публичным, желательно статическим IP и root-доступом. Шифрование обрабатывает charon в пространстве пользователя, поэтому при десятках подключений нагрузка на CPU растёт заметнее, чем у WireGuard.

apt update && apt upgrade -y
apt install -y strongswan xl2tpd

Вместо strongSwan можно взять libreswan — отличия в синтаксисе описаны в разборе L2TP/IPsec через libreswan; в Ubuntu 24.04 strongSwan ставится без сторонних PPA, поэтому используем его. Включите IP-форвардинг отдельным файлом в /etc/sysctl.d/:

cat > /etc/sysctl.d/99-l2tp.conf <<EOF
net.ipv4.ip_forward = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
EOF
sysctl --system

Строки про rp_filter особенно важны: строгая проверка обратного пути режет инкапсулированные пакеты IPsec, и туннель поднимается, а трафик не ходит. Заодно узнайте имя внешнего интерфейса командой ip route | grep default — на VPS это бывает eth0, ens3, enp1s0 — и подставляйте его везде, где ниже стоит eth0.

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

Отредактируйте /etc/ipsec.conf — конфиг демона charon:

config setup
    charondebug="ike 2, knl 2, cfg 2"
    uniqueids=no

conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    keyexchange=ikev1

conn L2TP-PSK
    authby=secret
    pfs=no
    auto=add
    keyingtries=3
    rekey=no
    ikelifetime=8h
    keylife=1h
    type=transport
    left=%defaultroute
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any

keyexchange=ikev1 — L2TP/IPsec с PSK строится на IKEv1, IKEv2 здесь не подходит без дополнительной логики (сравнение есть в статье IKEv2 или L2TP). type=transport — туннелирование берёт на себя L2TP; rightprotoport=17/%any ограничивает согласование протоколом UDP; uniqueids=no разрешает нескольким клиентам подключаться с одинаковым идентификатором, что важно при общем NAT. Сам ipsec.conf — starter-интерфейс strongSwan, объявленный устаревшим в пользу swanctl.conf, но в Ubuntu 24.04 он работает.

Задайте общий ключ в /etc/ipsec.secrets, сгенерировав его командой openssl rand -base64 32. Права 600 не формальность: файл содержит ключ открытым текстом.

: PSK "замените-на-длинный-случайный-ключ"

chmod 600 /etc/ipsec.secrets
systemctl enable --now strongswan-starter
systemctl restart strongswan-starter
ipsec statusall

Если юнит не найден, посмотрите systemctl list-units --all | grep -i swan: служба может называться и просто strongswan.

Настройка xl2tpd и PPP

Демон xl2tpd поднимает L2TP поверх IPsec. Отредактируйте /etc/xl2tpd/xl2tpd.conf:

[global]
port = 1701

[lns default]
ip range = 10.10.10.10-10.10.10.20
local ip = 10.10.10.1
require chap = yes
refuse pap = yes
require authentication = yes
name = l2tpd
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

ip range — пул адресов для клиентов, он же потолок одновременных подключений; local ip — адрес сервера внутри туннеля, пересекаться с пулом он не должен; ppp debug = yes полезен при настройке, потом его лучше выключить. Дальше — /etc/ppp/options.xl2tpd:

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
noccp
connect-delay 5000

require-mschap-v2 фиксирует протокол аутентификации, который требуют встроенные клиенты Windows и macOS; lcp-echo-interval и lcp-echo-failure определяют, через сколько сервер сочтёт клиента отвалившимся (здесь четыре проверки с интервалом 30 секунд). Логины и пароли PPP-уровня хранятся в /etc/ppp/chap-secrets:

# client    server    secret          IP addresses
vpnuser     l2tpd     StrongPass123!  *

Формат: имя клиента, имя сервера (совпадает с name из xl2tpd.conf), пароль, разрешённые IP (* — любой из пула). Файлу тоже поставьте права 600 и запустите демон:

systemctl enable --now xl2tpd
systemctl restart xl2tpd

Firewall и NAT

Откройте порты IPsec и разрешите ESP для подключений без NAT-T:

ufw allow OpenSSH
ufw allow 500,4500/udp
ufw allow proto esp from any to any
ufw enable

Порт 1701 наружу открывать не нужно: доступный снаружи, он позволяет обратиться к xl2tpd в обход шифрования. UFW по умолчанию блокирует форвардинг между интерфейсами — измените значение в /etc/default/ufw на DEFAULT_FORWARD_POLICY="ACCEPT", затем добавьте правило NAT в начало /etc/ufw/before.rules, перед строкой *filter:

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE
COMMIT

Подставьте имя своего интерфейса и перезапустите UFW: ufw disable && ufw enable.

Подключение клиентов

Windows — встроенный клиент: «Параметры → Сеть и Интернет → VPN → Добавить VPN-подключение», тип L2TP/IPsec с предварительным ключом, ключ из ipsec.secrets, логин и пароль из chap-secrets. Если сервер или клиент за NAT, Windows часто отказывается поднимать туннель без правки реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
Параметр: AssumeUDPEncapsulationContextOnSendRule (DWORD) = 2

После правки нужна перезагрузка. Значение 2 разрешает NAT-T и когда за NAT сервер, и когда клиент; это особенность Windows, а не ошибка вашей конфигурации.

macOS и iOS поднимают L2TP/IPsec через профиль конфигурации (.mobileconfig) или вручную в настройках сети. Оговорка на осень 2026 года: свежие версии iOS убрали L2TP из мастера добавления VPN, так что настраивается он только профилем. Android в большинстве прошивок сохраняет пункт «L2TP/IPSec PSK», но производители вычищают его из оболочек — проверьте наличие на модели заранее.

Роутеры (Mikrotik, Keenetic) настраиваются как L2TP/IPsec-клиент: адрес сервера, PSK, логин и пароль PPP. Так в туннель заворачивается вся локальная сеть разом — похожий сценарий для WireGuard разобран в статье про VPN на роутере для всего дома. Честный нюанс: если два клиента подключаются из-за одного публичного IP, right=%any может путать сессии — transport-режим различает пиров по адресу, а не по логину.

Проверка результата

L2TP/IPsec ломается послойно — так же и проверяйте: работает уровень ниже, идите к следующему.

1. Службы слушают порты. systemctl status strongswan-starter xl2tpd --no-pager и ss -lunp | grep -E ':500|:4500|:1701' должны показать обе службы active (running), charon на UDP 500 и 4500 и xl2tpd на 1701, а sysctl net.ipv4.ip_forward — единицу.

2. Пакеты клиента доходят. Сканировать UDP снаружи бесполезно, смотрите на сервере: запустите tcpdump -n -i any udp port 500 or udp port 4500 и подключитесь. Пусто — виноват firewall площадки или сеть клиента; пакеты идут, а связи нет — дело в конфигурации.

3. IPsec установился. ipsec statusall должен показать L2TP-PSK в состоянии ESTABLISHED с IP клиента, а ip xfrm state — пару security association. Пусто — разбирайтесь с PSK и параметрами IKE.

4. PPP-сессия поднялась. ip -br addr show type ppp должна показать строку вида ppp0 UP 10.10.10.1 peer 10.10.10.10. IPsec есть, а интерфейса нет — дело в chap-secrets или в имени сервера.

5. Трафик идёт через сервер. С клиента откройте 2ip.ru: должны отображаться публичный IP и страна сервера, а пинг до 10.10.10.1 — проходить. Адрес не сменился — смотрите маршруты на клиенте и правило MASQUERADE. Подробнее: как проверить IP и страну после туннеля.

6. Нет утечки DNS. Частая незамеченная проблема: IP сменился, а запросы имён уходят провайдеру. В списке резолверов на dnsleaktest.com не должно быть серверов вашего провайдера; если они там есть, проверьте ms-dns и настройки клиента — алгоритм в материале про закрытие DNS-утечек.

Не сошлось — читайте логи. Запустите journalctl -u strongswan-starter -f и journalctl -u xl2tpd -f в двух окнах и подключайтесь клиентом: у strongSwan ищите фазы согласования и слово authentication, у xl2tpd — сообщения pppd про CHAP. В тяжёлых случаях временно поднимите charondebug до уровня 4.

Разбор типичных граблей

Висит на проверке логина, потом обрывается. IPsec встал, L2TP-уровень не проходит. Проверьте, идентичны ли name в options.xl2tpd, xl2tpd.conf и втором поле chap-secrets, нет ли в пароле экранируемых клиентом символов и не закончились ли адреса в пуле.

Ошибка аутентификации сразу, без задержки. Обрыв на первых секундах почти всегда означает несовпадение PSK. Сверьте ключ посимвольно: частые причины — невидимый пробел в конце строки и автозамена кавычек при копировании через мессенджер. После правки достаточно ipsec rereadsecrets.

Работает с телефона, но не с Windows. Почти наверняка NAT-T: проверьте параметр реестра из раздела о клиентах и перезагрузку после его добавления. Реже виноват антивирус или корпоративная сеть, режущие исходящий UDP 500/4500, либо остановленная служба «Агент политики IPsec».

Не работает за NAT. Домашние роутеры часто некорректно обрабатывают IPsec: при трансляции ESP негде взять номер порта для различения сессий, поэтому первый клиент подключается, а второй — нет. Лечится доступностью порта 4500 и включением «IPsec passthrough» на роутере.

Двойной NAT у провайдера. Серый адрес у клиента обычно не мешает — исходящие через NAT-T проходят. Серый адрес у сервера смертелен: входящие UDP 500/4500 до него не дойдут. Сравните ip -4 addr с тем, что показывает внешний сервис проверки IP; адреса разные — нужен белый IP.

Security group блокирует UDP. Локальный ufw status показывает всё открытым, а на уровне панели площадки действует своя группа безопасности, и tcpdump не видит входящих пакетов. Проверьте правила в панели и не забудьте про ESP: там, где выбор ограничен «TCP/UDP/ICMP», нужна отдельная строка.

MTU и фрагментация. Пинг идёт, лёгкие сайты открываются, а тяжёлые страницы виснут на середине: пакеты после добавления заголовков не помещаются в MTU канала. Лечится строками mtu 1400 и mru 1400 в /etc/ppp/options.xl2tpd (снижайте шагами по 20) либо подстройкой TCP-сегмента:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Правило живёт до перезагрузки — закрепите его в секции *mangle файла /etc/ufw/before.rules. Метод подбора описан в статье про MTU и фрагментацию в VPN.

Рвётся каждые несколько минут. Смотрите rp_filter (должен быть 0) и lcp-echo-failure: агрессивные значения обрывают мобильных клиентов при потере связи.

Симптом → причина → что делать

Шпаргалка команд

# --- Службы ---
systemctl status strongswan-starter xl2tpd --no-pager  # состояние обеих разом
systemctl is-enabled strongswan-starter xl2tpd         # проверить автозапуск

# --- Порты и сеть ---
ss -lunp | grep -E ':500|:4500|:1701'   # кто слушает нужные UDP-порты
sysctl net.ipv4.ip_forward              # должно быть = 1

# --- IPsec и активные туннели ---
ipsec statusall                     # соединения, фазы, IP клиентов
ip xfrm state                       # security association на уровне ядра
ipsec rereadsecrets                 # перечитать ipsec.secrets без перезапуска
ip -br addr show type ppp           # интерфейсы ppp0, ppp1... = живые сессии

# --- Логи и трафик ---
journalctl -u strongswan-starter -f               # лог IPsec в реальном времени
journalctl -u xl2tpd -f                           # лог L2TP и pppd
tcpdump -n -i any udp port 500 or udp port 4500   # доходят ли пакеты клиента

Фишки и тонкая настройка

Несколько пользователей и изоляция. Заводите каждому отдельную строку в chap-secrets — так доступ отзывается по одному. Нужен фиксированный адрес, укажите его вместо *:

alice   l2tpd   ПарольAlice   10.10.10.11
bob     l2tpd   ПарольBob     10.10.10.12

По умолчанию клиенты видят друг друга внутри пула. Если это не нужно, запретите трафик между ppp-интерфейсами правилом iptables -A FORWARD -i ppp+ -o ppp+ -j DROP. Общие подходы — в материале про изоляцию пользователей VPN друг от друга.

Автозапуск после ребута. Проверяйте три вещи: службы в автозапуске, sysctl-параметры в файле /etc/sysctl.d/, правило MASQUERADE в before.rules, а не добавленное разово через iptables. Самая частая причина «после перезагрузки всё сломалось» — третий пункт, так что перезагрузите сервер сразу после настройки.

Ограничение доступа. Если клиентские адреса известны заранее, сузьте правило: ufw allow from 203.0.113.0/24 to any port 500,4500 proto udp.

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

Мониторинг подключений. Считайте ppp-интерфейсы через ip -br addr show type ppp; информативнее ipsec statusall, где видно IP каждого пира и время жизни сессии. Для истории увеличьте глубину журнала systemd (SystemMaxUse).

Когда пора менять протокол. Скажем прямо: если клиентам можно поставить приложение, WireGuard будет быстрее и проще в поддержке. L2TP/IPsec оправдан в двух ситуациях: софт ставить нельзя или клиент — оборудование, у которого выбора нет. Промежуточный вариант — IKEv2 с сертификатами: тоже поддерживается штатно в Windows и Apple, но лишён слоя L2TP и стабильнее за NAT. Разумно держать про запас второй протокол, например OpenVPN.

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