MAATRIX / Блог / L2TP/IPsec-сервер на AlmaLinux 9: пошаговая установка

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

MAATRIX

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 ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →