WireGuard или OpenVPN не запускается на OpenVZ: проверка TUN/TAP

Почему WireGuard или OpenVPN на OpenVZ может не запуститься вообще

Если tun0 или wg0 не появляется, сначала нужно определить уровень отказа. Переустановка пакетов в этот момент редко даёт новую информацию: гораздо полезнее понять, дошёл ли VPN до создания сетевого интерфейса вообще.

Обычно проблема выглядит так: пакет установлен, systemd пытается поднять сервис, но дальше появляется Permission denied, Operation not permitted, ошибка открытия TUN/TAP или отказ при создании интерфейса. В другом сценарии интерфейс уже есть, но клиент не получает трафик. Внешне обе ситуации выглядят как «VPN не работает», хотя диагностируются совершенно по-разному.

Удобно сразу разделить четыре состояния:

Эта таблица сразу отсекает несколько ложных направлений. Если tun-test падает с Operation not permitted, настройки маршрутизации пока вообще не участвуют в проблеме. Если tun0 уже создан, повторная смена прав на /dev/net/tun тоже не выглядит разумным первым шагом: этот уровень уже пройден.

Первую конкретную ошибку обычно дают сервис и журнал:

systemctl status 'openvpn*'
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 --no-pager
ip link
ip addr
ls -l /dev/net/tun

В systemctl status не нужно останавливаться на строке failed. Ищите первую техническую причину перед завершением процесса: невозможно открыть устройство, создать интерфейс, прочитать ключ, применить адрес, выполнить PostUp-команду или занять порт. Именно эта строка определяет следующую ветку диагностики.

Как убедиться, что VPS действительно работает на OpenVZ

Тип виртуализации нужно подтвердить до команд вроде modprobe tun или попытки собирать модуль WireGuard. В KVM гостевая система имеет собственное ядро. OpenVZ-контейнер работает на ядре хостовой ноды, и это напрямую влияет на то, какие сетевые возможности root может изменить самостоятельно.

Первая проверка:

systemd-detect-virt

В контейнерной среде команда может вернуть название обнаруженной технологии виртуализации. Но одна команда не должна быть единственным доказательством: название зависит от среды и того, как конкретная версия systemd распознаёт контейнер.

Что делать, если systemd-detect-virt не показывает ожидаемый результат

Если команда возвращает неожиданный ответ, none либо вообще не даёт информации, сравните несколько источников:

virt-what
hostnamectl
uname -r
cat /proc/1/cgroup

virt-what установлен не в каждой системе. Его отсутствие означает только отсутствие утилиты. uname -r показывает ядро, которое видит контейнер, но сам по себе не отвечает на вопрос, какой тип VPS вы купили. /proc/1/cgroup тоже нельзя трактовать по одной случайной строке без учёта версии системы.

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

Здесь часто возникает характерная ошибка: после Operation not permitted начинают устанавливать kernel headers и повторять modprobe. Но если нужную операцию запрещает уровень контейнера, пакеты внутри VPS не меняют этот запрет.

После подтверждения контейнерной виртуализации вопрос становится конкретным: разрешено ли именно этому OpenVZ-контейнеру использовать TUN/TAP и создавать тот тип интерфейса, который нужен VPN.

Есть ли в OpenVZ рабочий /dev/net/tun

Для OpenVPN мало увидеть файл /dev/net/tun. Нужно подтвердить три вещи: устройство существует, процесс может его открыть, а контейнер способен создать через него TUN- или TAP-интерфейс. Проверка только через ls отвечает лишь на первый вопрос.

Начните с:

ls -l /dev/net/tun
stat /dev/net/tun
test -c /dev/net/tun && echo TUN-device-exists

Если последняя команда выводит TUN-device-exists, /dev/net/tun существует как character device. Всё. Работоспособность OpenVPN этим ещё не доказана.

/dev/net/tun отсутствует

Если ls отвечает No such file or directory, OpenVPN не сможет открыть стандартное TUN/TAP-устройство по этому пути. Проверьте, существует ли сам каталог:

ls -ld /dev/net

Ручное создание device node нельзя считать окончательным исправлением. Можно получить файл с правильным типом и номером устройства, но при первой реальной операции контейнер всё равно ответит Operation not permitted. В таком случае проблема не в отсутствии имени /dev/net/tun, а в том, что хост не разрешает контейнеру нужную операцию.

/dev/net/tun есть, но появляется Permission denied

Permission denied означает, что путь найден, но процесс не получает доступ. Сначала проверьте обычные Unix-права и пользователя:

ls -l /dev/net/tun
id

Если тест выполняется от root, права устройства выглядят нормальными, но доступ всё равно запрещён, переходите к проверке самого интерфейса. Не стоит автоматически лечить такую ситуацию через chmod 666: файловые права и ограничения контейнера — разные уровни.

/dev/net/tun есть, но появляется Operation not permitted

Здесь уже важна конкретная операция. Device node может быть виден и открываться, но создание интерфейса блокируется политикой контейнера или отсутствующей сетевой capability.

При наличии capsh можно посмотреть capabilities процесса:

capsh --print

Однако такой вывод не заменяет реальный TUN-тест. Даже список capabilities без ошибки ещё не доказывает, что OpenVZ разрешит конкретную операцию с устройством.

Дополнительная проверка:

cat /dev/net/tun

На системе, где устройство удаётся открыть, можно получить сообщение вроде File descriptor in bad state. Для TUN это принципиально отличается от No such file or directory или Permission denied: файл открылся, но обычное чтение через cat не соответствует способу работы с TUN. Точный текст может отличаться между системами, поэтому cat остаётся вспомогательным тестом.

TUN работал раньше, но после перезапуска VPS пропал

Если OpenVPN работал до перезапуска, переноса или другого изменения окружения, не стоит автоматически считать старую проверку TUN актуальной. Начните заново с ls -l /dev/net/tun, затем повторите создание тестового интерфейса.

Сценарий показательный: вчера tun0 успешно поднимался, сегодня /dev/net/tun исчез либо ip tuntap add впервые отвечает Operation not permitted. В такой ситуации сначала фиксируют изменение нижнего уровня, а уже потом открывают конфигурацию OpenVPN.

Если устройство исчезло или тот же тест, который раньше проходил, теперь блокируется, в обращение провайдеру стоит передать именно этот факт. Не нужно гадать, что произошло на хостовой ноде.

Проверку TUN удобно держать в голове как пять ступеней: device node существует, устройство открывается, интерфейс создаётся, OpenVPN его настраивает, трафик проходит. Сбой на каждой ступени ведёт в свою ветку диагностики.

Как проверить TUN независимо от WireGuard и OpenVPN

Самый прямой способ отделить OpenVPN от ограничений OpenVZ — создать временный TUN-интерфейс без запуска VPN. Если операция не проходит, конфигурация OpenVPN к этой ошибке ещё не имеет отношения.

От root выполните:

ip tuntap add dev tun-test mode tun
ip link show tun-test

Если команда отработала успешно, в ip link появится tun-test. Интерфейсу не нужен IP-адрес, и он не обязан быть UP. Проверяется только способность системы создать TUN.

После теста:

ip link delete tun-test

tun-test создался: что именно это доказало

Успешный tun-test доказывает, что контейнер видит TUN/TAP-устройство и обладает достаточными правами для создания TUN-интерфейса через текущий сетевой стек. Это сильный результат, но он не доказывает, что конфигурация OpenVPN правильная.

После успешного теста уже имеет смысл разбирать:

• какой конфигурационный файл запускает systemd;
• правильно ли задан dev;
• доступны ли сертификаты и ключи;
• свободен ли порт;
• не падает ли OpenVPN на другой директиве;
• что происходит с tun0 после старта сервиса.

Именно здесь круг поиска резко сужается. Ограничение OpenVZ на базовое создание TUN уже не выглядит основной причиной.

Operation not permitted: что уже можно исключить

Если:

ip tuntap add dev tun-test mode tun

возвращает Operation not permitted, нет смысла начинать с сертификатов OpenVPN, параметра remote или правил MASQUERADE. Команда падает до запуска OpenVPN и до появления пользовательского VPN-трафика.

Проверьте ещё раз тип виртуализации, /dev/net/tun и права процесса. Если базовая операция стабильно блокируется от root, следующая точка — ограничения контейнера или хостовой ноды.

No such file or directory: почему одного mknod недостаточно

Если тест сообщает об отсутствии TUN-устройства, проблема находится ещё ниже. Иногда в старых инструкциях предлагают вручную создать /dev/net/tun. Само наличие device node, однако, не выдаёт контейнеру право использовать устройство.

После любых изменений результат нужно подтверждать тем же тестом:

ip tuntap add dev tun-test mode tun

Если файл появился, а команда сменила No such file or directory на Operation not permitted, диагностика продвинулась: теперь видно, что узел устройства существует, но операция запрещена. Это уже совсем другой диагноз.

TUN работает, а TAP нет: что проверять в OpenVPN

Успешный тест TUN не гарантирует работу конфигурации OpenVPN с dev tap. Оба типа интерфейса используют /dev/net/tun, но создаются в разных режимах: TUN передаёт IP-пакеты третьего уровня, TAP работает как Ethernet-интерфейс второго уровня.

Сначала посмотрите, что требует конкретная конфигурация OpenVPN:

grep -E '^[[:space:]]*dev([[:space:]]|$)|^[[:space:]]*dev-type([[:space:]]|$)' /path/to/config.conf

Если используется dev tun, тест tun-test соответствует нужному сценарию. Если указано dev tap, нужен отдельный TAP-тест.

Как проверить TAP без запуска OpenVPN

ip tuntap add dev tap-test mode tap
ip link show tap-test

После проверки:

ip link delete tap-test

Если tun-test создаётся, а tap-test нет, нельзя писать «TUN/TAP полностью работает». Вы доказали доступность только TUN-режима. Дальше нужно разбираться с конкретным запретом TAP в окружении.

Почему TAP может потребовать дополнительной сетевой настройки

Создание tap0 — только первый этап. TAP часто используют в сценариях второго уровня, где дальше участвуют bridge-интерфейсы и Ethernet-сегмент. Если tap0 создаётся, но нужная сеть через него не работает, это уже не доказательство проблемы TUN/TAP-устройства.

Проверьте:

ip link
ip addr
bridge link
bridge vlan

Команды bridge доступны при наличии соответствующих утилит iproute2 и нужны только если конфигурация действительно использует bridge. Добавлять мост «на всякий случай» не стоит.

Для этой статьи достаточно провести границу: TUN и TAP тестируются отдельно, а успешное создание TAP ещё не гарантирует правильную работу bridge. После появления tap0 диагностика переходит на сетевую конфигурацию.

Почему WireGuard на OpenVZ требует отдельной проверки

Рабочий TUN/TAP в OpenVZ не доказывает доступность нативного WireGuard. WireGuard создаёт собственный тип сетевого интерфейса через поддержку ядра, поэтому его нужно проверять отдельно.

Начните с пользовательских утилит:

wg --version
wg

WireGuard установлен, wg --version отвечает — и здесь часто делают слишком ранний вывод, что сервер уже поддерживает WireGuard. На самом деле эта проверка подтверждает только наличие wireguard-tools.

wireguard-tools установлен, но wg0 не появляется

Проверьте сервис:

systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 --no-pager

Затем отделите конфигурацию wg-quick от способности системы создать сам интерфейс:

ip link add dev wg-test type wireguard
ip link show wg-test

После успешного теста:

ip link delete wg-test

Теперь важна сама ошибка. Operation not permitted ведёт в сторону сетевых прав и политики контейнера. Ошибка о неизвестном или неподдерживаемом типе интерфейса указывает в сторону поддержки WireGuard со стороны ядра и окружения. Точный текст зависит от системы, поэтому ориентируйтесь не на совпадение строки из инструкции, а на этап, на котором операция завершилась.

wg-test создаётся, а wg-quick@wg0 всё равно падает

Это уже хороший результат: способность создать нативный WireGuard-интерфейс подтверждена. После этого ошибка wg-quick может находиться в конфигурации, адресах, маршрутах или вспомогательных командах PreUp, PostUp, PreDown и PostDown.

Сначала снова смотрите журнал:

journalctl -u wg-quick@wg0 --no-pager

Если в журнале видно, что wg0 был создан, а падение произошло на следующей команде, не нужно возвращаться к вопросу поддержки WireGuard ядром. Этот уровень уже пройден.

Полезно проверить, не остался ли интерфейс после неудачного запуска:

ip link show wg0
ip addr show wg0
wg show wg0

Например, ошибка на firewall-команде из PostUp и невозможность создать wg0 — разные неисправности, хотя обе могут привести к статусу failed у одного systemd unit.

TUN работает, а WireGuard нет

Противоречия здесь нет. OpenVPN может успешно поднять tun0, поскольку контейнеру предоставлен TUN/TAP, а ip link add dev wg-test type wireguard одновременно может завершаться отказом. Это разные механизмы.

Userspace-реализации WireGuard способны работать через TUN без нативного WireGuard-интерфейса ядра, но это другая архитектура. Она не служит универсальным обходом любого ограничения OpenVZ: если контейнеру закрыт сам TUN или нужные сетевые операции, userspace-вариант тоже упрётся в ограничения.

Почему OpenVPN не запускается даже при наличии TUN

Если тестовый TUN или TAP создаётся успешно, проблема уже не сводится к доступу OpenVZ к /dev/net/tun. Следующий уровень — сам OpenVPN: какой конфигурационный файл запускается, на какой директиве процесс падает и успевает ли он создать рабочий интерфейс.

Как понять, какой systemd unit реально запускает OpenVPN

Название сервиса зависит от дистрибутива, версии пакета и схемы размещения конфигураций. Вместо того чтобы предполагать конкретное имя, сначала посмотрите доступные units:

systemctl list-units --type=service 'openvpn*'
systemctl list-unit-files 'openvpn*'

После этого открывайте статус уже конкретного экземпляра:

systemctl status <openvpn-unit>
journalctl -u <openvpn-unit> --no-pager

Это особенно полезно, когда на сервере лежат несколько конфигураций, а пользователь редактирует один файл и перезапускает другой unit. Снаружи выглядит так, будто OpenVPN «игнорирует настройки», хотя сервис просто читает другой конфиг.

Сервис падает до создания tun0

Если после старта tun0 вообще не появляется, найдите первую содержательную ошибку в журнале. Несколько типичных направлений:

Для диагностики конфигурацию можно запустить в foreground:

openvpn --config /path/to/config.conf --verb 4

Не запускайте второй экземпляр поверх уже работающего сервиса на том же порту. Если нужно исследовать production-конфигурацию, сначала убедитесь, какой процесс сейчас активен.

tun0 создаётся и тут же исчезает

Это хороший пример, почему одного ip link после неудачного запуска иногда недостаточно. OpenVPN может создать tun0, выполнить несколько следующих операций, получить ошибку и при завершении удалить интерфейс.

В таком сценарии смотрите журнал запуска, а не только конечное состояние:

journalctl -u <openvpn-unit> --no-pager

Если видно, что TUN/TAP открылся и интерфейс был создан, первоначальная проблема доступа к /dev/net/tun уже исключается. Дальше может падать назначение адреса, маршрут, script, firewall-команда или другая часть конфигурации.

Для занятого порта:

ss -lntup

Для состояния интерфейсов:

ip link
ip addr

Самая показательная ситуация — OpenVPN уже поднял tun0. После этого бессмысленно десятый раз менять права на /dev/net/tun. Этот этап уже пройден.

Что делать с modprobe tun и modprobe wireguard внутри OpenVZ

modprobe tun и modprobe wireguard часто попадают в инструкции, написанные для физического сервера или KVM. В OpenVZ результат этих команд нельзя трактовать тем же способом, потому что контейнер не управляет отдельным гостевым ядром.

Версия ядра, которую видит контейнер:

uname -r

Дополнительные команды:

lsmod
modprobe tun
modprobe wireguard

Что означает Module not found внутри контейнера

Сообщение о том, что модуль не найден, само по себе не доказывает неисправность Linux внутри VPS. Контейнер может не иметь локального набора модулей, соответствующего ядру хостовой ноды, потому что загрузкой модулей управляет не гостевая система.

Проверить локальные файлы можно:

ls -ld /lib/modules
ls -ld /lib/modules/$(uname -r)

Если каталога для текущего ядра внутри контейнера нет, бессмысленно сразу делать вывод, что «нужно установить headers и собрать модуль». Сначала вернитесь к реальной операции, которая требуется приложению.

Для OpenVPN:

ls -l /dev/net/tun
ip tuntap add dev tun-test mode tun

Для нативного WireGuard:

ip link add dev wg-test type wireguard

Эти проверки ближе к реальной задаче, чем сам факт успеха или ошибки modprobe.

Почему успешный modprobe тоже ничего не гарантирует

Даже если команда не выводит ошибку, остаётся отдельный вопрос: разрешена ли нужная операция конкретному контейнеру. Для TUN это подтверждается созданием tun-test. Для WireGuard — созданием wg-test.

Именно поэтому цепочка:

modprobe tun
echo $?

не должна завершать диагностику. Нулевой код выхода ещё не означает, что OpenVPN получит рабочий TUN в этом OpenVZ-контейнере.

В контейнере root остаётся root для файлов, процессов, приложений и множества сетевых настроек внутри доступных namespaces. Но root контейнера не становится администратором OpenVZ-хоста. Это и есть граница, из-за которой советы для KVM иногда приводят в тупик.

VPN запустился, но трафик не проходит: TUN уже не виноват

Если tun0, tap0 или wg0 создан и остаётся в системе, следующий класс проблем находится выше: forwarding, маршруты, NAT, firewall, AllowedIPs WireGuard или обратный маршрут. Сам интерфейс уже поднялся. Теперь нужно найти, где теряется пакет.

Начните с IPv4 forwarding:

sysctl net.ipv4.ip_forward

Для VPS, который должен маршрутизировать IPv4-трафик между VPN и другой сетью, требуется разрешённый forwarding:

net.ipv4.ip_forward = 1

Если значение 0, маршрутизация IPv4 ядром выключена. Если попытка изменить параметр внутри OpenVZ завершается системным запретом, это уже пограничная ситуация между настройкой пользователя и политикой контейнера: результат стоит передать провайдеру вместе с остальной диагностикой.

Дальше:

ip route
ip rule

Для WireGuard:

wg show

Смотрите время последнего handshake, счётчики transfer и allowed ips. Handshake говорит, что peer смог связаться с другой стороной и выполнить криптографический обмен. Он не доказывает, что маршрут до нужной сети настроен правильно.

VPN-интерфейс есть, но клиент не выходит в интернет

Здесь хорошо работает метод трёх точек. Не переставляйте правила firewall вслепую — посмотрите сам пакет.

Точка A: приходит ли пакет на VPN-интерфейс.

tcpdump -ni tun0
tcpdump -ni wg0

Используйте интерфейс, который существует в вашей конфигурации.

Точка B: выходит ли тот же трафик через внешний интерфейс.

tcpdump -ni <external-interface>

Точка C: возвращается ли ответ на внешний интерфейс и уходит ли он обратно в VPN.

Эти три наблюдения дают гораздо больше информации, чем простой факт «ping не работает».

Предположим, клиент отправляет ICMP через VPN. На wg0 запросы видны, а на внешнем интерфейсе нет ни одного соответствующего пакета. Это уже конкретный результат: проблема находится между VPN-интерфейсом и egress, поэтому проверяют forwarding, firewall и маршрутизацию.

Другой сценарий: запрос виден и на wg0, и на внешнем интерфейсе, но ответа нет. Тогда WireGuard уже передал пакет куда нужно внутри сервера. Дальше смотрят, с каким исходным адресом пакет вышел, нужен ли NAT, существует ли обратный маршрут и отвечает ли вообще удалённая сторона.

Как проверить NAT и firewall без случайного копирования правил

Для iptables:

iptables -S
iptables -t nat -S

Для nftables:

nft list ruleset

Универсальное правило MASQUERADE из чужой инструкции может быть синтаксически правильным и при этом не совпадать ни с вашей VPN-подсетью, ни с внешним интерфейсом. Сначала определите реальную схему через ip addr и ip route, затем проверяйте существующие правила.

WireGuard показывает handshake, но трафика почти нет

При рабочем handshake проверьте AllowedIPs на обеих сторонах, маршруты и счётчики transfer:

wg show

Если отправленные байты растут, а принятые почти не меняются, пакеты уходят, но ответный путь не работает. Если счётчики не растут вообще, нужно проверить, попадает ли нужный адрес под AllowedIPs и соответствующий маршрут.

После этого снова применим метод трёх точек. Handshake — не конец диагностики. Это только доказательство, что базовая связь между peers существует.

Когда проблему нельзя исправить внутри OpenVZ и нужен хостер или KVM

Если независимый тест TUN, TAP или WireGuard завершается системным запретом ещё до запуска VPN, конфигурация приложения не исправит эту ошибку. Часть возможностей OpenVZ выдаётся контейнеру с хостовой ноды, и root внутри VPS не может изменить их самостоятельно.

Но и отправлять провайдеру каждую ошибку OpenVPN не нужно. Если tun-test создаётся, wg-test создаётся или VPN уже поднял рабочий интерфейс, значительная часть дальнейшей диагностики находится внутри VPS.

Что собрать перед обращением в поддержку

Хорошее обращение к провайдеру должно показывать, на каком уровне возник запрет. Для OpenVPN/TUN достаточно небольшой последовательности:

systemd-detect-virt
ls -l /dev/net/tun
ip tuntap add dev tun-test mode tun

Если используется TAP:

ip tuntap add dev tap-test mode tap

Для WireGuard:

ip link add dev wg-test type wireguard

Добавьте точный текст ошибки и результат systemctl status или journalctl. Если функция работала до перезапуска или переноса VPS, так и напишите: раньше тот же тест проходил, теперь возвращает конкретную ошибку. Это намного полезнее фразы «VPN перестал работать».

Короткий чек-лист перед сменой VPS

• Подтверждён реальный тип виртуализации.
• Проверено наличие и тип /dev/net/tun.
• TUN протестирован независимо от OpenVPN.
• Если конфигурация использует TAP, отдельно протестирован TAP.
• WireGuard протестирован через создание нативного интерфейса, а не только через wg --version.
• Прочитана первая содержательная ошибка systemd/journal.
• Проверено, создаётся ли и остаётся ли tun0, tap0 или wg0.
• Если интерфейс существует, проверены forwarding, маршруты, NAT и firewall.
• При проблеме с трафиком путь пакета проверен через tcpdump хотя бы в двух точках.
• modprobe не используется как единственное доказательство поддержки TUN или WireGuard.
• Если системный запрет подтверждён независимым тестом, результаты сохранены для провайдера.

Переход на KVM нужен не потому, что OpenVZ принципиально несовместим с VPN. OpenVPN способен работать в контейнере с доступным TUN/TAP, а WireGuard — в среде, где хост поддерживает и разрешает соответствующий интерфейс. KVM становится более подходящим вариантом, когда проекту нужен собственный контроль над ядром, модулями и сетевыми возможностями без зависимости от политики контейнерной ноды.

Если tun-test не создаётся, OpenVPN пока оставляем в покое. Если TUN работает, а OpenVPN падает с Options error, проблема уже в приложении. Если tun0 или wg0 поднялся, а пакет не доходит до назначения, смотрим маршрут. Такая лестница диагностики и позволяет отличить ограничение OpenVZ от обычной ошибки VPN-конфигурации без перебора случайных команд.