L2TP/IPsec-сервер на AlmaLinux 9: пошаговая установка
L2TP/IPsec — не самый быстрый протокол VPN, но у него есть козырь, которого нет ни у WireGuard, ни у OpenVPN: встроенная поддержка во всех современных ОС без установки стороннего клиента. Windows, macOS, iOS и Android умеют подключаться к нему из коробки. Ниже — как поднять L2TP/IPsec-сервер на AlmaLinux 9 с нуля: пакеты из EPEL, конфигурация IPsec и xl2tpd, открытие портов 500/4500/1701 в firewalld и работа с SELinux.
Содержание
Обсудить статью, задать вопрос или начать новую тему
Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.
Перейти в сообщество →Когда имеет смысл выбирать L2TP/IPsec
Прежде чем разворачивать протокол, стоит честно понять его место. L2TP/IPsec — это двойная инкапсуляция: данные заворачиваются в L2TP-туннель, а весь этот трафик дополнительно шифруется IPsec. Двойной слой означает лишний оверхед на каждом пакете и заметно более медленное установление соединения по сравнению с WireGuard — там счёт идёт на доли секунды, здесь на секунды.
Так для чего он вообще нужен сегодня? Практическая причина одна — совместимость. Если нужно подключить корпоративный ноутбук с заблокированной установкой стороннего софта, старый роутер с урезанной прошивкой или устройство, где по политике безопасности разрешены только штатные VPN-клиенты ОС, L2TP/IPsec часто остаётся единственным вариантом без танцев с APK-файлами и профилями конфигурации. Если ограничений на установку приложений нет, для личного использования почти всегда удобнее WireGuard или OpenVPN — сравнение протоколов разобрано в статье о выборе между WireGuard и OpenVPN. Ниже разворачиваем именно L2TP/IPsec, исходя из того, что нужна нативная поддержка ОС.
Ещё нюанс: описанная здесь схема работает на предварительном общем ключе (PSK) плюс логин/пароль пользователя — это не то же самое, что сертификатная IPsec-инфраструктура для site-to-site туннелей между офисами, там конфигурация заметно сложнее.
Готовим систему и подключаем EPEL
Работаем на свежем AlmaLinux 9. Сначала обновите систему и подключите репозиторий EPEL — он понадобится для пакета xl2tpd, которого нет в базовых репозиториях:
sudo dnf update -y
sudo dnf install -y epel-release
sudo dnf install -y libreswan xl2tpd ppp
Здесь два разных источника пакетов. libreswan — это реализация IPsec, которую Red Hat поставляет прямо в базовых репозиториях RHEL-семейства: именно её NetworkManager использует под капотом для собственных IPsec-подключений, и это самый предсказуемый выбор для AlmaLinux 9 (в отличие от strongSwan, который на этой платформе не входит в стандартные репозитории). А вот xl2tpd, реализующий L2TP-туннелирование, в базовых репозиториях отсутствует и берётся именно из EPEL — отсюда акцент на этом репозитории в самом начале установки.
Проверьте версии и что оба пакета встали:
rpm -q libreswan xl2tpd
Арендуйте сервер под свои задачи!
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Арендовать серверНастраиваем IPsec: libreswan
Все настройки libreswan лежат в /etc/ipsec.conf и подключаемых файлах /etc/ipsec.d/*.conf. Откройте основной конфиг и в раздел config setup добавьте параметры NAT-трансляции и виртуальных подсетей:
config setup
protostack=netkey
nat_traversal=yes
virtual-private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.10.10.0/24
uniqueids=no
virtual-private перечисляет приватные диапазоны, которые IPsec обязан учитывать как «внутренние» сети клиентов, а восклицательный знак перед подсетью туннеля (10.10.10.0/24 — её мы зададим дальше в xl2tpd) исключает её саму, чтобы не было конфликта. Далее опишите соединение L2TP/IPsec отдельным файлом /etc/ipsec.d/l2tp-psk.conf:
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
dpddelay=30
dpdtimeout=120
dpdaction=clear
Обратите внимание на type=transport — в отличие от туннельного режима IPsec, здесь шифруется только сам L2TP-трафик поверх уже установленного соединения, а не создаётся отдельная IP-сеть на уровне IPsec. Именно эта комбинация ожидается связкой libreswan + xl2tpd. Ключ PSK пропишите в /etc/ipsec.secrets:
%any %any: PSK "ваш-длинный-случайный-ключ"
Сгенерировать случайный ключ можно так: openssl rand -base64 24. Не используйте короткие словарные фразы — PSK подбирается брутфорсом так же, как обычный пароль.
Прежде чем запускать службу, включите форвардинг пакетов и отключите пару параметров ядра, которые типично ломают L2TP/IPsec на многоинтерфейсных VPS — приём/отправку ICMP-редиректов и строгую проверку обратного пути:
cat <<'EOF' | sudo tee /etc/sysctl.d/99-ipsec.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
EOF
sudo sysctl -p /etc/sysctl.d/99-ipsec.conf
Без отключения rp_filter пакеты, приходящие обратно через loopback-интерфейс xl2tpd (об этом — в разделе про firewalld), в некоторых конфигурациях сети отбрасываются ядром как «пришедшие не с того интерфейса», хотя на первый взгляд всё настроено верно. Это одна из самых частых причин, по которой туннель поднимается, а трафик через него не ходит.
Запустите и включите автозагрузку IPsec:
sudo systemctl enable --now ipsec
sudo ipsec verify
Команда ipsec verify — встроенная диагностика libreswan: она проверит форвардинг, права на конфиги и базовую готовность системы, и явно укажет, что именно не так, если есть проблема.
Настраиваем xl2tpd
Основной конфиг — /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
refuse chap = yes
refuse pap = yes
require authentication = yes
name = L2TPServer
ppp debug = no
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
ip range — пул адресов, которые получат клиенты, local ip — адрес самого сервера внутри этой служебной подсети (она же указана в virtual-private выше со знаком исключения). Далее настройте параметры PPP-сессии в /etc/ppp/options.xl2tpd:
require-mschap-v2
ms-dns 1.1.1.1
ms-dns 8.8.8.8
asyncmap 0
auth
mtu 1410
mru 1410
crtscts
lock
hide-password
local
name l2tpd
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
Значения mtu/mru 1410 — не случайное число, а компенсация под накладные расходы двойной инкапсуляции L2TP+IPsec: стандартные 1500 байт здесь почти гарантированно приведут к фрагментации и «тормозящим» соединениям на части сайтов. Если после установки увидите зависающие HTTPS-страницы при рабочем пинге — начните диагностику именно с MTU. И последнее — логины пользователей в /etc/ppp/chap-secrets:
# client server secret IP addresses
vpnuser l2tpd ваш-пароль *
Значение * в последнем столбце означает, что клиенту выдаётся любой свободный адрес из пула ip range. Для каждого пользователя — своя строка с уникальным паролем. Запустите xl2tpd:
sudo systemctl enable --now xl2tpd
Открываем порты в firewalld: 500, 4500, 1701
Три порта играют разные роли. UDP 500 — это IKE, начальное согласование ключей IPsec. UDP 4500 — NAT-T, тот же IKE, но упакованный для прохождения через NAT (актуально почти всегда, поскольку большинство клиентов сидят за NAT мобильного или домашнего роутера). UDP 1701 — собственно L2TP, но с оговоркой: после того как IPsec расшифровал пакет, xl2tpd получает его через loopback-интерфейс, а не напрямую из сети.
sudo firewall-cmd --permanent --add-port=500/udp
sudo firewall-cmd --permanent --add-port=4500/udp
sudo firewall-cmd --permanent --zone=trusted --add-interface=lo
sudo firewall-cmd --permanent --add-masquerade
sudo firewall-cmd --reload
Строка с --zone=trusted --add-interface=lo — та самая грабля, из-за которой соединение вроде бы поднимается (IKE проходит, PSK принят), а L2TP-сессия внутри так и не устанавливается. Loopback-интерфейс не всегда числится в доверенной зоне на свежей установке AlmaLinux, и firewalld фильтрует трафик до xl2tpd на порту 1701 точно так же, как внешний. Явное включение lo в trusted снимает блокировку. Порт 1701/udp наружу, в публичную зону, открывать не нужно — снаружи на него никто не обращается, всё идёт через 500 и 4500.
--add-masquerade включает NAT для трафика из туннельной подсети 10.10.10.0/24 наружу — без него клиенты подключатся и получат внутренний адрес, но не получат доступа в интернет. Проверить правила: sudo firewall-cmd --list-all и sudo firewall-cmd --zone=trusted --list-interfaces.
SELinux: на что смотреть при сбоях
AlmaLinux 9 идёт с SELinux в режиме enforcing по умолчанию, и это иногда пугает при первой настройке нестандартных служб. Хорошая новость: политики для pluto (процесс libreswan) и для xl2tpd/pppd в стандартной поставке уже покрывают стандартные порты 500, 4500 и 1701, а также типовые пути конфигов — при установке из официальных репозиториев (BaseOS и EPEL) с портами по умолчанию отдельно настраивать SELinux обычно не требуется.
Проблемы возникают при отклонении от стандартной схемы: нестандартный порт IPsec, нетиповые пути конфигов, непривычные опции pppd. Если после установки соединение не поднимается, а journalctl и логи libreswan/xl2tpd ничего подозрительного не показывают, проверьте SELinux:
sudo ausearch -m avc -ts recent
sudo journalctl -t setroubleshoot --since "10 min ago"
Если в выводе ausearch есть записи type=AVC denied, это точный признак блокировки политикой. Дальше — стандартный путь диагностики: если денай связан с нестандартным портом, промаркируйте его вручную под нужный контекст, например:
sudo semanage port -a -t ipsec_port_t -p udp 4500
(команда завершится ошибкой «уже существует», если порт стандартный и контекст уже назначен — это нормально и означает, что дело не в порте). Для нетиповых денаев, не связанных с портами, сгенерируйте точечную политику через audit2allow вместо того, чтобы просто выключать enforcing:
sudo ausearch -m avc -ts recent | audit2allow -M l2tp-local
sudo semodule -i l2tp-local.pp
Полностью переводить SELinux в permissive ради одного сервиса не стоит — это отключает защиту для всей системы, а не только для VPN. Точечная политика решает проблему без такого компромисса.
Проверка и подключение клиента
Убедитесь, что обе службы подняты и IPsec готов принимать соединения:
sudo systemctl status ipsec xl2tpd
sudo ipsec status | grep l2tp-psk
Клиента настраивайте штатными средствами ОС: тип подключения — L2TP/IPsec с PSK, адрес сервера — публичный IP VPS, общий ключ — из ipsec.secrets, логин и пароль — из chap-secrets. После подключения на сервере это видно в логе sudo journalctl -u xl2tpd -f и появлением новой записи в ipsec status. Проверить, что трафик реально идёт через туннель: с клиента выполните curl ifconfig.me — в ответе должен быть IP вашего сервера, а не домашнего провайдера.
Если IKE проходит (500/4500 отрабатывают), но L2TP-сессия не устанавливается — почти всегда забыт lo в зоне trusted либо PSK на клиенте и сервере не совпадает. Есть сессия, но нет интернета — проверяйте форвардинг и masquerade. Соединение рвётся или страницы зависают на середине загрузки — дело в MTU, уменьшайте mtu/mru до 1400 и переподключайтесь.
Арендуйте сервер под свои задачи!
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Арендовать серверНужны сами нейросети для контента?
Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.
Частые вопросы
Почему для xl2tpd нужен EPEL, а для libreswan нет?
Libreswan — часть стандартной поставки RHEL-совместимых систем и лежит в BaseOS, так как используется и другими компонентами (например, NetworkManager). xl2tpd в официальные репозитории AlmaLinux не входит и ставится только из EPEL.
Можно ли использовать strongSwan вместо libreswan?
Технически да, но на AlmaLinux 9 strongSwan не входит в стандартные и EPEL-репозитории в готовом виде, и его пришлось бы собирать самостоятельно или подключать сторонний репозиторий. Libreswan — предсказуемый выбор именно для этой платформы.
Почему соединение поднимается, а интернета через VPN нет?
Чаще всего забыт net.ipv4.ip_forward=1 либо правило --add-masquerade в firewalld. Проверьте оба пункта в указанном порядке.
Обязательно ли открывать порт 1701 наружу в публичной зоне firewalld?
Нет. Снаружи в 1701 никто не стучится — весь внешний трафик идёт через 500 и 4500, а 1701 используется только локально между libreswan и xl2tpd через loopback, для чего интерфейс lo должен быть в зоне trusted.
Насколько L2TP/IPsec медленнее WireGuard на одинаковом канале?
Разница ощутима из-за двойной инкапсуляции и более тяжёлого согласования ключей, но точную цифру для вашего канала и железа надёжнее замерить самостоятельно — она сильно зависит от процессора сервера и качества сети между вами и им.
Обсудить статью, задать вопрос или начать новую тему
Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.
Перейти в сообщество →