Железобетонный VPN в 2026: пошаговый чек-лист харденига, права и firewall

Почему хардениг VPN-сервера в 2026 уже не роскошь, а обязанность

Атаки стали быстрее, а ошибки все те же

Давайте честно: VPN-сервер — это ворота в нашу сеть. Если на воротах замок ржавый, остальное мало поможет. В 2026 году злоумышленники автоматизировали более 80 процентов атак на публичные туннельные точки, боты сканируют UDP и TCP порты, проверяют версии протоколов, дефолтные конфиги и даже разницу в задержках при рукопожатии. Есть ли у нас право на ошибку? Нет. Любая оплошность — и данные клиентов могут утечь, а мы будем оправдываться неделями. Лучше вложиться в профилактику.

Хардениг — это не боль, а дисциплина

Многие путают хардениг с паранойей. На самом деле это про дисциплину и повторяемые практики: минимум прав, закрытый периметр, четкие правила маршрутизации, регулярный аудит. Делаете один раз хорошо — и потом просто поддерживаете. Мы не строим бетонную стену без окон, мы ставим умные двери, камеры и будильники. И да, это совсем не страшно.

Производительность и безопасность дружат

Есть миф, что безопасность убивает скорость. Неправда. Современные стеки — WireGuard с ChaCha20-Poly1305, OpenVPN на TLS 1.3 и AES-GCM — дают высокую пропускную способность даже при строгом nftables и системных ограничениях. Правильные sysctl, eBPF фильтры, разделение плоскостей управления и данных — и мы получаем и безопасность, и скорость. Где подвох? В настройке. Но для этого у нас и есть чек-лист.

Модель угроз и выбор протокола: WireGuard, OpenVPN или IPSec

Формулируем модель угроз

Прежде чем крутить гайки, стоит зафиксировать, от кого и чего мы защищаемся. Типовая модель угроз для VPN-сервера в 2026 году: массовые сканеры, брутфорс ключей управления, эксплуатация уязвимостей в демонах, фишинговые атаки на админов, попытки DDoS и лимит-экзост, утечки ключей и конфигов, ошибки маршрутизации и DNS-утечки. Отдельным пунктом идут облачные риски: злоупотребление метаданными инстансов, слабые политики IAM, чрезмерно открытые security groups. Все это влияет на выбор стека и настройки.

WireGuard: современно и минималистично

WireGuard стал де-факто стандартом по простоте и скорости. Небольшой код, сильная криптография по умолчанию, ключи Ed25519, статeless-архитектура. Он идеален для сайт-то-сайт и доступа пользователей. Но у WireGuard нет встроенной аутентификации по паролю или многофакторной авторизации на уровне протокола, все держится на ключах. Значит, управление ключами и политика выдачи — в фокусе. Хотим SSO? Придется добавлять надстройки, например, контроль доступа на уровне координатора или прокси.

OpenVPN: гибкая классика с TLS 1.3

OpenVPN не уходит. Там, где нужны сложные PKI, CRL, клиентские сертификаты, авторизация через PAM, LDAP или RADIUS, он удобен. В 2026 мы включаем только TLS 1.3, используем ECDHE с X25519 или P-256, шифры AES-256-GCM, и ставим жесткие renegotiation политики. Да, сложнее в управлении, но зато многофакторность и гранулярные ACL доступны из коробки через плагины и скрипты.

IPSec и гибриды

IPSec в режиме IKEv2 отлично подходит для межсайтовых туннелей и интеграции с сетевым оборудованием. Он зрелый, производительный, но требует терпения в настройках и хороших политик шифрования. В реальном мире мы часто видим гибриды: WireGuard для удаленных сотрудников, IPSec между дата-центрами, OpenVPN для специфичных клиентских интеграций. Не надо спорить, «что лучше». Нужно выбирать под задачу и под нашу модель угроз.

Минимальная база системы: платформа, обновления, ядро, файловые системы

Дистрибутив и жизненный цикл

Планируем жить спокойно 5 лет? Берем LTS. В 2026 это Ubuntu 24.04 LTS, Debian 12, Rocky Linux 9, AlmaLinux 9 или Alpine 3.20+ для легковесных инсталляций. Чем меньше по базе, тем лучше: меньше пакетов — меньше уязвимостей. Сразу фиксируем репозитории, включаем unattended-upgrades или аналог, но обновления ядра и критических сервисов проводим управляемо, с окнами и откатами.

LTS-ядро и безопасность

Держимся LTS-веток ядра 6.6 или 6.10 со свежими патчами дистрибутива. Проверяем включенность ретполин и спектр-митигураций, включаем kernel lockdown, ограничиваем небезопасные интерфейсы: kptr_restrict=2, dmesg_restrict=1, правим unprivileged_userns_clone по политике, отключаем опасные BPF для непремивилигерованных юзеров или настраиваем bpf.strict_mode. Для WireGuard лучше модуль ядра, а не DKMS.

Файловые системы и монтирование

Отдельные разделы под /, /var, /var/log, /var/log/audit и, при возможности, /tmp. Монтируем /tmp и /var/tmp как noexec,nosuid,nodev. Для /home и /var — nodev,nosuid. На проде полезен immutable-флаг на конфиги, которые редко меняются. Журналы отдаём на отдельный диск или том, чтобы DDoS логами не положил систему. Где возможно, включаем fs-целостность и ретроактивный контроль через IMA или по крайней мере AIDE.

Время и источники энтропии

NTP — это не мелочь. Несинхронизированное время ломает сертификаты, ломает аудит, делает расследование адом. Используем chrony с несколькими серверами, ограничиваем источники и разрешения. Для криптографии смотрим на rngd или jitterentropy, чтобы у виртуалок не было проблем с энтропией на старте.

Принцип минимальных прав: пользователи, systemd, capabilities, MAC

Пользователи и группы

Запускаем VPN-демоны от выделенного системного пользователя без логина и шелла. Папки конфигов и ключей с правами 750 или 700, файлы ключей 600. Никаких world-readable секретов. Админам — sudo по ролям, без NOPASSWD на все подряд, и обязательный audit для повышений привилегий.

Хардениг unit-файлов systemd

Systemd даёт массу защитных флажков. Используем DynamicUser где можно, ProtectSystem=strict, ProtectHome=true, PrivateTmp=true, PrivateDevices=true, NoNewPrivileges=true, MemoryDenyWriteExecute=true, RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX, LockPersonality=true, ProtectClock=true, ProtectKernelTunables=true, IPAddressDeny=any с переопределением только нужных, CapabilityBoundingSet= и AmbientCapabilities с точным списком. Чуть больше строк — и мы резко сужаем поверхность атаки.

Linux capabilities и chroot

Если демону не нужен CAP_NET_ADMIN после старта — отбрасываем. WireGuard часто требует админских сетевых прав только при инициализации интерфейса — остальное можно делегировать через отдельный помощник. Избегаем запуска от root по умолчанию, где возможно — отделяем инициализацию и runtime. Chroot или bubblewrap для вспомогательных процессов снижает риск побега.

SELinux или AppArmor

В 2026 проще жить с профилями AppArmor на Ubuntu или SELinux Enforcing в RHEL-подобных. Используем готовые политики и не выключаем их ради «быстрее починить». Профиль, который отрезает демону доступ к непредусмотренным путям и системным вызовам, часто спасает при RCE. Да, иногда придется править политику, но это инвестиция.

Криптография и управление ключами: без магии

Современные наборы шифров

OpenVPN: только TLS 1.3, шифры TLS_AES_256_GCM_SHA384 или TLS_CHACHA20_POLY1305_SHA256, ECDHE с X25519, подписи ECDSA P-256 или Ed25519, RSA 3072 минимум, лучше 4096 для совместимости. WireGuard уже использует ChaCha20-Poly1305, Curve25519, BLAKE2s — отлично по умолчанию. IPSec IKEv2: AES-GCM, PRF-HMAC-SHA2, PFS на ECP256 или X25519. Никаких устаревших SHA-1, 3DES и RC4 — даже в «наследие».

Постквантовая готовность

В 2026 мы уже тестируем гибриды: X25519+Kyber для обмена ключами, Ed25519+Dilithium для подписей там, где стек позволяет. В продуктиве включаем гибрид только после тестов совместимости. Для OpenVPN это перспектива через сторонние патчи и библиотеки, а вот для TLS-терминации на фронте — уже реальность. Главное — не фантазировать, а следовать рекомендациям выбранного дистрибутива и криптопровайдера.

PKI, выдача и отзыв

У нас есть изолированная CA, офлайн, с понятным сроком выпуска и политикой отзыва. Выпуск клиентских сертификатов — по заявкам, с аудитом, с автоматическим истечением и обязательной привязкой к конкретному пользователю и устройству. CRL и OCSP обновляются по расписанию, а не «как получится». Для WireGuard — строгое управление ключами: запрещаем самодельные конфиги, используем координацию через контроллер или конф-генератор с журналированием.

Хранение секретов и ротация

Секреты — не в git и не в wiki. Используем хранилища вроде Vault или встроенные KMS облака, а для файловых конфигов — sops с ключами в KMS или age. Ротация ключей и сертификатов по расписанию: раз в 90 или 180 дней, а с компрометацией — немедленно. При увольнении сотрудника его доступы ревоким в тот же день. Автоматизация спасает, ручные процессы ломаются в пятницу вечером.

Firewall и периметр: nftables, eBPF и здравый смысл

Базовая политика «запрещено все, кроме»

В 2026 nftables — стандарт. Политика по умолчанию drop, разрешаем только конкретные порты и протоколы: UDP 51820 для WireGuard, UDP или TCP 1194 для OpenVPN, IKEv2 500 и 4500 для IPSec, плюс SSH для админки, но с ограничениями по источникам. Локальный loopback разрешаем, все остальное — через явные правила. Таблицы для input, forward, output — каждая со своей логикой, а не единый «суп-набор».

Rate limit и анти-DDoS

Добавляем ограничение на частоту новых соединений и пакетов рукопожатия. Для UDP — ограничиваем по IP и по подсети, используем sets и maps для динамики. На уровне ядра включаем tcp_syncookies, увеличиваем очереди backlog и буферы, но в разумных пределах. Не забываем про conntrack — слежение за состояниями должно быть включено и настроено, иначе внезапно упремся в лимиты.

Маршрутизация, NAT и изоляция

Для WireGuard часто делаем policy routing: трафик из интерфейса wg0 — по своим таблицам, с явными правилами. NAT — только где нужно и только для конкретных диапазонов. Гостевые сети и админские — раздельно, нет «все в одну корзину». Для OpenVPN используем client-config-dir и настройки, чтобы выдавать клиентам только нужные маршруты и DNS. Split-tunnel на стороне клиента? Только по согласию и с политикой.

IPv6, DNS и метрики

IPv6 — не просто «выключить». Если включен, то настраиваем адресацию, RA и firewall наравне с IPv4. DNS-утечки закрываем: указываем корпоративные резолверы через push или peer-конфиг, запрещаем обращение к внешним DNS из VPN-сети, если это не часть дизайн-решения. Метрики и логи собираем отдельно, желательно через выделенный интерфейс управления, чтобы мониторинг не мешал боевому трафику.

Отключаем лишнее: сокращаем поверхность атаки

Сервисы и пакеты

Смотрим systemctl list-unit-files и ss -tulpen. Отключаем все, что не связано с VPN и базовой поддержкой: принтеры, avahi, автообнаружения, демон обновлений GUI, rpcbind и т.п. Пакеты чистим, оставляя только необходимое. Чем меньше кода — тем меньше漏洞. И да, «на всякий случай» — это плохой аргумент.

Sysctl-профиль

Жесткий профиль sysctl закрывает класс атак. Для IPv4: net.ipv4.conf.all.rp_filter=1, accept_redirects=0, send_redirects=0, accept_source_route=0, tcp_syncookies=1, icmp_echo_ignore_broadcasts=1. Для IPv6: net.ipv6.conf.all.accept_ra=0 на сервере, где не нужен RA, и запрет source route. Отключаем ответ на странные пакеты, ограничиваем маршрутизацию только там, где это нужно VPN-интерфейсу. Не забываем persistent-режим через конфиги, а не echo в рантайме.

Контейнеры или bare-metal

Запуск VPN в контейнере возможен, но требует продуманной модели прав и капабилити. Rootless-подходы, cgroup v2, ограниченные netns — все это работает, но производительность и сложность растут. Для высоконагруженных точек и простоты часто лучше VM или bare-metal, чтобы минимизировать дополнительный слой рисков. Если контейнер — то только с явно заданными capability set и seccomp профилями.

Облако и метаданные

В облаке закрываем доступ к метаданным инстансов с публичного интерфейса, используем IMDSv2-подобные механизмы, security groups с deny-all и явными allow, private subnet для админки и отдельный bastion. Ключи доступа храним в KMS, а не на диске сервера. Snapshot-ы шифруем, а доступ к ним контролируем так же строго, как к прод-базам данных.

Аудит, логирование и мониторинг: видеть, знать, реагировать

Системный аудит

Включаем auditd, фиксируем попытки эскалации прав, изменения конфигов, доступ к ключам и unit-файлам. Журналы journald отправляем удаленно, с ротацией и защитой от заполнения диска. На уровне VPN-софта — логируем только то, что нужно для разбора инцидентов, без избыточного PII. Логи — это не свалка, а инструмент.

Мониторинг и метрики

Графики живут дольше слов. Снимаем метрики по соединениям, латентности, ошибкам рукопожатия, заполненности буферов, CPU и IRQ нагрузке. Prometheus-экспортеры для системы и VPN-софта, алерты по SLO: доступность точки входа, время установления туннеля, пиковая нагрузка. Плюс простая синтетика: скрипт, который поднимает тестовый туннель раз в N минут и проверяет маршруты.

Контроль целостности и EDR

AIDE или интегрити-мониторинг на уровне пакетов и конфигов дает раннее предупреждение. Легкий EDR-агент с правилами для отслеживания нетипичного поведения процесса VPN, анализа команд админа, блоков для подозрительных бинарей — это не роскошь. Важно не перегнуть: сигналы должны быть actionable, иначе все выключат.

Процедуры реагирования

Инциденты случаются. У нас должен быть короткий план: кто дежурный, как изолировать узел, как перевести трафик на резерв, какие журналы собрать и куда отправить. Чек-лист на одну страницу решает больше проблем, чем двадцать слайдов, забытых где-то в Confluence. Тренируемся раз в квартал.

Эксплуатация и процессы: доступ, обновления, резерв

Админский доступ и MFA

SSH только по ключам, с отключенным паролем и ограничением по IP. MFA для привилегированного доступа — через PAM и FIDO2-ключи, где возможно. Сеансные прокси, журналы команд, минимальные sudo-правила. Если надо в прод — делаем это осмысленно и оставляем следы. Никаких «общих» учеток, каждая операция — персональная.

Обновления без боли

Регулярные окна, канарейки, бекап конфигов, автоматический откат. Перед обновлением — снимок VM или конфигов, после — проверка контрольного списка: поднялся ли интерфейс, прошел ли трафик, работает ли DNS. Библиотеки криптографии и ядро — только с тестированием. Мы не герои, мы инженеры.

Резервирование и отказоустойчивость

Две точки в разных зонах или дата-центрах, Anycast IP или геораспределенный DNS, синхронизация списков клиентов и ключей. Конфиги в git с шифрованием, CI для проверки синтаксиса, CD для развертывания через API. Регулярные тесты аварийного переключения: не узнаем о проблеме на клиентской встрече.

Комплаенс и приватность

Если мы обрабатываем персональные данные, у нас есть политика логирования и хранения. IP-адреса — это персональные данные по многим законам. Сроки ретенции, методы анонимизации, ограничение доступа к журналам — все этому место в регламенте. CIS Benchmarks для ОС и VPN, ISO 27001 процессы, внутренние проверки — пусть звучит скучно, зато потом не стыдно.

Пошаговый чек-лист харденига VPN-сервера

Подготовка платформы

1. Выберите LTS-дистрибутив и зафиксируйте репозитории. 2. Обновите систему, установите LTS-ядро, включите необходимые митигурации. 3. Разделите диски, задайте жесткие mount-опции, выделите том под логи. 4. Настройте chrony, несколько источников времени, ограничьте доступ. 5. Установите AIDE и первичную базу целостности.

Пользователи и сервисы

1. Создайте системного пользователя для VPN, без шелла. 2. Проставьте права на каталоги и файлы ключей. 3. Харденьте unit-файлы systemd: ProtectSystem, PrivateTmp, CapabilityBoundingSet и др. 4. Отключите и удалите лишние службы и пакеты. 5. Включите SELinux Enforcing или AppArmor профиль.

Криптография и ключи

1. Настройте только современные шифры и TLS 1.3, если это OpenVPN. 2. Организуйте изолированную CA, процесс выдачи и отзыва. 3. Введите обязательную ротацию ключей и сертификатов. 4. Перенесите секреты в защищенное хранилище. 5. Спланируйте PQC-пилот и совместимость.

Сеть и firewall

1. Включите nftables с политикой deny-by-default. 2. Разрешите только нужные порты и адресные семьи. 3. Введите rate limit на рукопожатия и новые соединения. 4. Разделите маршрутизацию, настройте NAT только где нужно. 5. Закройте DNS-утечки, настройте IPv6 осознанно.

Аудит, мониторинг, реагирование

1. Запустите auditd, настройте правила на ключевые операции. 2. Уведите логи на удаленный коллектор, настройте ротацию. 3. Соберите метрики и алерты по SLO. 4. Описывайте план реагирования и учите команду. 5. Регулярно проверяйте целостность и конфигурацию.

Эксплуатация и DR

1. Введите MFA и строгие sudo-политики. 2. Организуйте окна обновлений с канарейками и откатом. 3. Разверните вторую точку и проверьте фейловер. 4. Храните конфиги в репозитории с шифрованием и ревизиями. 5. Проведите тест восстановления из бекапа и зафиксируйте результаты.

Частые ошибки и реальные кейсы

Оставили все по умолчанию

Компания запустила OpenVPN на дефолтном профиле TLS 1.2, с SHA-1 и без CRL. Одна утечка ключа — и злоумышленник оставался в сети неделями. Исправили, когда клиенты заметили странную активность. Итог: обновили до TLS 1.3, включили CRL, ввели автоматическую ротацию. Больновато, но эффективно.

Игнорирование IPv6

Отключили IPv6 «чтобы было проще». В результате клиентские устройства всё равно имели глобальный IPv6 и ходили мимо корпоративного DNS, получая смешные, а потом грустные результаты. Исправили: настроили IPv6 в VPN, добавили нужные маршруты и правила firewall, закрыли утечки.

Нет планов на отказ

Один сервер, один диск, одна точка входа. DDoS прилетел в пятницу, инженеры проснулись в понедельник. Теперь у них две точки, резервные каналы и алерты. Простая архитектурная избыточность решает больше, чем супермощный сервер.

Секреты в репозитории

Да, это до сих пор случается. Ключи WireGuard коммитят в git, а потом удивляются, что кто-то подключился ночью из другой страны. Решение простое: sops, KMS и политические запреты. И алерты на слово private_key в PR не помешают.

Практические настройки: нюансы, которые экономят часы

Полезные sysctl для VPN

Точечные параметры часто убирают лаги и странности. Увеличиваем net.core.rmem_max и wmem_max, настраиваем net.core.default_qdisc=fq и tcp_congestion_control=bbr2 или cubic по тестам, следим за net.netfilter.nf_conntrack_max в зависимости от памяти и профиля нагрузки. Но каждое изменение — через тест, а не «кто-то в интернете сказал».

nftables: наборы и карты

Используем sets для хранения разрешенных адресов админов, а maps — для динамических лимитов. Это делает правила читабельнее и быстрее. Логирование в nft через ограничение на burst, чтобы не зафлудить диски. Отладка — nft monitor trace, но на проде осторожно.

WireGuard: политика AllowedIPs

Самая частая ошибка — давать 0.0.0.0/0 всем, где это не нужно. Ставим ровно те подсети, к которым клиент должен ходить. Для межсайтовых туннелей — явные сети, никакой лишней транзитной маршрутизации. Keepalive на нестабильных сетях — 25 секунд, но это не серебряная пуля.

OpenVPN: серверный профиль

tls-version-min 1.3, cipher AES-256-GCM, ncp-ciphers AES-256-GCM, reneg-sec под политику, verify-x509-name для клиентов, crl-verify, tls-crypt для защиты рукопожатия от сканеров. Плагин auth-pam для MFA и ограниченные скрипты в client-connect, если это часть процесса. И да, не забываем о —explicit-exit-notify для UDP.

Контроль качества и непрерывное улучшение

Бенчмарки и SLO

Без целевых метрик мы плаваем в тумане. Определяем SLO: время установления туннеля, пропускная способность при N клиентах, средняя латентность до ключевых сетей. Прогоняем бенчмарки при каждом крупном изменении. Сравниваем графики «до» и «после», а не верим ощущениям.

Безопасный CI/CD для конфигов

Конфиги VPN — такой же код. Ветки, ревью, статические проверки синтаксиса, тестовые среды. Разворачиваем через pipeline, а не вручную. Это убирает человеческий фактор и упрощает откаты. GitOps-подход снижает температуру и увеличивает предсказуемость.

Обратная связь от пользователей

Если пользователи жалуются на «медленно», не спорим, а замеряем. Часто проблемой оказывается DNS, нерациональная маршрутизация или узкое место в Wi-Fi у клиента. Чек-лист диагностики с пятью шагами экономит часы: ping маршрутов, DNS-resolve, проверка MTU, трассировка и тест пропускной способности.

Тренды 2026

Гибридные PQC-профили в TLS, повсеместный переход на nftables, более строгие политики systemd, рост популярности eBPF XDP для фильтрации, Zero Trust на уровне устройств, где устройство допускается в VPN только при прохождении постур-чеков. Мы не обязаны внедрять все, но понимать тренды полезно.

FAQ: коротко о главном

Нужно ли переходить с OpenVPN на WireGuard прямо сейчас

Если у вас зрелая PKI, MFA и отлаженные процессы вокруг OpenVPN, нет срочности. WireGuard дает простоту и скорость, но потребует перестройки управления доступами. Правильный ответ зависит от ваших процессов и интеграций.

Можно ли безопасно держать VPN в контейнере

Можно, но осторожно. Нужны ограниченные capabilities, seccomp, rootless, четкая сеть и понимание производительности. Для высоких нагрузок и простоты чаще берем VM или bare-metal.

Как сделать MFA для WireGuard

На уровне протокола — никак. Делают через контроль выдачи и жизненного цикла ключей, через прокси-доступ или внешние агенты, которые проверяют постур устройства и пользователя перед выдачей конфигурации.

Стоит ли выключать IPv6

Лучше настроить правильно. Отключение часто ведет к утечкам и неожиданным обходам. Если IPv6 не нужен, отключайте последовательно на интерфейсах и в приложениях. Если нужен — настраивайте firewall и маршруты так же строго, как для IPv4.

Как часто ротировать ключи и сертификаты

Минимум раз в 90-180 дней для пользовательских, корневые — по политике и риску. Важнее иметь автоматизацию и отработанный процесс отзыва при инциденте. Без этого сроки — просто цифры.

Какие логи хранить и как долго

Только необходимые для расследования: установление сессий, метаданные соединений, ошибки. Персональные данные — минимум. Сроки хранения определяем политикой и законом, обычно от 30 до 180 дней, а доступ строго ограничиваем.

Что важнее: firewall или SELinux

Это не выбор. Firewall контролирует сеть, SELinux или AppArmor — доступ процессов. Вместе они создают глубину защиты. Уберите одно — и получите дыру там, где не ждете.