WireGuard VPN не работает на Ubuntu: как найти и устранить причину

WireGuard устроен так, что почти ничего не сообщает о своих проблемах. Пока трафика нет, интерфейс просто молчит, а когда что-то ломается, ошибки вроде «не удалось подключиться» не появляется. Соединение между клиентом и сервером либо устанавливается, либо нет, и по статусу в приложении причину не определить.

При этом ломается WireGuard всегда по одним и тем же причинам, и их не так много. Если проверять их в правильном порядке, причина обычно находится за пару минут. Начнём с интерфейса, который не запускается, затем разберём случаи, когда соединение не устанавливается вовсе, потом ситуации, когда туннель поднят, но трафик через него не идёт, и отдельно поговорим про DNS, который часто подводит уже после того, как всё остальное починили. Команды проверены на Ubuntu 24.04 LTS, есть пометки для 22.04 и вышедшей в 2026 году 26.04.

Первым делом смотрим на wg show, а не на конфиг

Когда VPN перестаёт работать, обычно сразу открывают конфиг и начинают искать ошибку в настройках. Но гораздо быстрее выполнить одну команду, сначала на клиенте, потом на сервере:

В выводе важны три строки. Latest handshake показывает время последнего успешного соединения. Если строка пустая или с того момента прошло больше двух минут, туннель сейчас не работает, даже когда приложение показывает зелёный статус. Transfer показывает объём отправленных и полученных данных. Когда в полученных стоит ноль, ваши пакеты уходят, но ответа на них нет, и виноват тут почти всегда файрвол, NAT или ошибка в маршрутизации. Endpoint на сервере заполняется публичным адресом клиента после первого же дошедшего пакета, и если поле осталось пустым, до сервера не дошло вообще ничего.

Для мониторинга удобнее команда sudo wg show wg0 latest-handshakes: она выводит время в секундах от начала эпохи Unix. Ноль здесь означает не «очень давно», а то, что соединение не устанавливалось ни разу с момента запуска интерфейса.

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

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

Интерфейс не поднимается

Ошибка RTNETLINK answers: Operation not supported

Такая ошибка при команде wg-quick up wg0, обычно вместе с Protocol not supported, почти всегда означает одно: не загружен модуль ядра wireguard. Проверяем командой lsmod | grep wireguard, и если вывод пустой, пробуем загрузить его вручную через sudo modprobe wireguard.

Если и это не помогает, вариантов остаётся два. Либо включён Secure Boot, который не пропускает неподписанный модуль, и тогда его нужно подписать или отключить Secure Boot. Либо сервер работает на контейнерной виртуализации вроде LXC или OpenVZ, а там модуль должен быть загружен на физическом хосте, и внутри контейнера сделать с этим ничего нельзя, прав не хватит.

Здесь многое решает не конфигурация WireGuard, а сама платформа, на которой работает сервер. У VPS на полноценной KVM-виртуализации есть собственное ядро, поэтому вопрос с модулем снимается сам собой и не зависит от настроек общего хоста.

Ошибка resolvconf: command not found

С этой ошибкой сталкивается заметная часть тех, кто ставит WireGuard на Ubuntu впервые. Скрипт wg-quick прописывает DNS через утилиту resolvconf, но в свежих версиях системы её нет по умолчанию, вместо неё работает systemd-resolved. В результате запуск интерфейса обрывается ровно на той строке, где вызывается resolvconf.

Починить можно тремя способами. Проще всего поставить пакет openresolv командой sudo apt install openresolv, он работает как совместимая замена. Можно сделать символическую ссылку с resolvconf на resolvectl, и тогда wg-quick продолжит работать, обращаясь на самом деле к systemd-resolved. А можно убрать строку DNS из конфига совсем и настроить резолвинг вручную, что надёжнее всего, если вы хотите контролировать DNS самостоятельно.

Подключение не устанавливается

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

Закрыт UDP-порт. WireGuard работает через один порт, по умолчанию это 51820. Если он заблокирован хотя бы в одном месте на пути пакета, соединение не установится. Проверять нужно сразу два файрвола: у облачного провайдера и локальный на самом сервере, где порт открывается командой sudo ufw allow 51820/udp. Захват трафика через tcpdump покажет, доходят ли пакеты и на какой стороне искать блокировку.

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

Ошибка в AllowedIPs. Этот параметр часто принимают за список разрешённых адресов, но на самом деле он работает как таблица маршрутизации и определяет, куда сервер отправляет ответы. Каждому клиенту нужен свой диапазон, обычно один адрес с маской /32. Когда диапазоны двух клиентов пересекаются, сервер перестаёт понимать, кому адресован пакет, и соединение устанавливается лишь на секунду, а потом обрывается.

Соединение держится пару минут и пропадает. Это типичный таймаут NAT. Домашний роутер или мобильный оператор после простоя забывают, какому внутреннему адресу соответствует внешний UDP-порт, и ответные пакеты от сервера просто некуда доставить. Лечится всё одной строкой в конфиге клиента, который находится за NAT: PersistentKeepalive = 25. Каждые 25 секунд наружу уходит небольшой пакет, и роутер не успевает забыть про соединение.

На сервере сбились часы. Причина неочевидная, ведь вся остальная конфигурация выглядит правильной. WireGuard использует метки времени, чтобы защититься от повторной отправки старых пакетов, поэтому при расхождении часов больше чем на пару минут вполне рабочие попытки соединения отклоняются как устаревшие. Такое бывает на только что созданных виртуальных машинах или после восстановления сервера из паузы. Исправляется командой sudo timedatectl set-ntp true, а проверить результат можно через timedatectl status, где должна появиться строка System clock synchronized: yes.

Перепутаны ключи. Эту причину стоит проверять в последнюю очередь: встречается она заметно реже остальных, но выглядит точно так же, поэтому за неё часто хватаются раньше времени. Публичный ключ клиента, записанный на сервере, должен совпадать с тем, который генерируется из приватного ключа клиента, и наоборот. Отличить публичный ключ от приватного на глаз невозможно, оба выглядят как случайный набор символов, так что перепутать их при копировании проще простого. Сверить можно командой echo “приватный_ключ” | wg pubkey и сравнить результат с тем, что записано у второй стороны. PresharedKey, если он используется, тоже должен совпадать посимвольно.

Рукопожатие проходит, но интернета нет

Если wg show показывает, что соединение установлено, но выхода в сеть через туннель всё равно нет, проблема уже не в связи между узлами, а в том, что происходит с трафиком дальше на сервере. Начинаем с переадресации пакетов:

Настройку лучше держать в отдельном файле внутри /etc/sysctl.d, тогда она не потеряется при перезагрузке. Дальше понадобится правило маскарадинга, которое подменяет адрес отправителя на адрес сервера:

И тут проявляется особенность Ubuntu: даже при верных правилах iptables трафик может резать UFW, потому что он ведёт собственный набор правил поверх iptables и настраивается отдельно. Обычно нужные строки добавляют в тот же блок PostUp:

Отдельно стоит проверить, как на самом деле называется внешний интерфейс, командой ip -br link. В туториалах почти везде фигурирует eth0, но на современных образах VPS он часто носит имя ens3 или enp1s0. Если в конфиге указано неверное имя, правило маскарадинга не сработает, причём молча, без единого сообщения об ошибке, и трафик будет теряться. А если клиенты подключаются к уже существующей локальной сети, понадобится ещё и proxy ARP: echo 1 | sudo tee /proc/sys/net/ipv4/conf/all/proxy_arp, эту строку тоже добавляем в файл sysctl.d.

Пинг проходит, SSH работает, а сайты не открываются

Если картина именно такая, почти наверняка виноват MTU. WireGuard упаковывает каждый пакет в собственный UDP-пакет, и на эту упаковку уходит от 60 до 80 байт. Поэтому при стандартном MTU канала в 1500 байт интерфейсу WireGuard по умолчанию ставят 1420. Небольшие пакеты вроде пинга, DNS-запроса или начала TCP-соединения проходят при любом значении, из-за чего туннель какое-то время выглядит вполне рабочим. Проблемы начинаются, когда пакет становится крупнее, например при загрузке страницы целиком.

Подобрать рабочее значение можно пингом с запретом фрагментации, постепенно уменьшая размер пакета: ping -M do -s 1372 10.66.66.1. Найденное значение прописывают прямо в конфиге интерфейса строкой MTU = 1380.

Типичный MTU по типу канала

Чаще всего с этим сталкиваются там, где пакет по дороге к серверу проходит дополнительную инкапсуляцию: операторский NAT, мобильные сети, спутниковые каналы вроде Starlink. На таких маршрутах фактический MTU обычно ниже стандартного, а автоматический подбор не срабатывает, потому что операторы режут нужные для него ICMP-пакеты. Когда поправить нужно только TCP-трафик, достаточно правила iptables –clamp-mss-to-pmtu.

Туннель работает, а сайты по именам не открываются

Вопреки распространённому мнению, строка DNS в блоке Interface к самому WireGuard отношения не имеет. Протокол занимается только передачей зашифрованных пакетов и про доменные имена ничего не знает. За эту строку отвечает скрипт wg-quick: пока туннель поднят, он подменяет системные настройки резолвера, а при отключении возвращает всё обратно. Сбои случаются как раз в этом механизме, и бывают они трёх видов.

В первом случае не резолвится вообще ничего, и виновата тут обычно уже знакомая нам ошибка с resolvconf. Во втором имена резолвятся нормально, но сами запросы идут в обход туннеля, из-за чего видно, какие сайты вы открываете, хотя весь остальной трафик уже зашифрован. Третий случай самый неприятный: служба управления DNS на клиенте, а на Ubuntu это обычно systemd-resolved, через несколько секунд после подключения тихо перезаписывает настройки, выставленные wg-quick.

Посмотреть, какой DNS-сервер используется на самом деле, можно командой resolvectl status wg0. Если сервер находится внутри VPN-сети, его адрес нужно отдельной строкой с маской /32 добавить в AllowedIPs. Иначе система пойдёт к нему через обычный интернет-канал вместо туннеля и ответа не дождётся.

После перезагрузки или обновления Ubuntu всё перестаёт работать

Причин тут обычно три. Первая связана с перезапуском службы: если вы поменяли только список пиров, хватит reload для wg-quick@wg0, но при изменении PostUp, PostDown или Address нужен полноценный restart, иначе правки не применятся. Вторая причина, это конфликт netplan и wg-quick. Netplan умеет настраивать WireGuard сам через секцию tunnels, однако при повторном netplan apply новые пиры подхватываются не всегда, и порой интерфейс приходится удалять вручную командой ip link del dev wg0. Если же на сервере одновременно работает служба wg-quick@wg0 и лежит описание того же интерфейса в netplan, они начинают мешать друг другу, поэтому стоит оставить что-то одно.

Третья причина, это версия системы. Поддержка Ubuntu 20.04 закончилась в мае 2025 года, для новых серверов сейчас берут 24.04 с поддержкой до 2029 года, а в апреле 2026 вышла 26.04. На серверах, которые обновляли с 20.04, обычно вылезают сразу обе знакомые проблемы: ошибка resolvconf и переставшее работать правило маскарадинга. Последнее случается потому, что при крупном обновлении имя сетевого интерфейса нередко меняется само, хотя настройки WireGuard никто не трогал.

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

Таблица: что проверить и как исправить

Симптом, проверка, причина и решение

В каких сценариях что чаще всего ломается

• Личный VPN с подключением с телефона через мобильный интернет. Здесь почти всё сводится к MTU и таймаутам NAT, так что время уходит на подбор PersistentKeepalive и правильного значения MTU.
• Доступ небольшой команды к внутренней инфраструктуре. Чаще всего мешают пересечения в AllowedIPs, недостающие маршруты во внутренние подсети, правила UFW и необходимость в proxy ARP.
• Прямая связь между двумя серверами по схеме site to site. Всплывают пересекающиеся подсети, отсутствие обратного маршрута и проблемы с MTU, когда один туннель идёт внутри другого.
• WireGuard внутри Docker или LXC. На первый план выходят доступность модуля ядра, права контейнера NET_ADMIN и параметр src_valid_mark.
• Сервер, недавно обновлённый со старой версии Ubuntu. Обычно приходят сразу и ошибка resolvconf, и переименование интерфейса, потому что причина у них одна.

Ошибки, из-за которых чаще всего приходится всё это чинить

• Правила iptables добавляют прямо в работающую систему вместо PostUp, и после перезагрузки они пропадают.
• В AllowedIPs на стороне сервера ставят 0.0.0.0/0, из-за чего в туннель уходит гораздо больше трафика, чем планировалось.
• Меняют порт в конфиге, но забывают открыть новый в файрволе провайдера.
• Копируют имя eth0 из туториала, не проверив, как интерфейс называется на самом деле.
• Оставляют конфиг с правами по умолчанию, и система начинает предупреждать, что файл доступен всем пользователям.
• Судят о состоянии подключения по иконке в приложении вместо вывода wg show.
• Проверяют исправление одним пингом и не смотрят отдельно, работает ли DNS.

Итог

Практически всё, что ломается в WireGuard на Ubuntu, упирается не в криптографию, а в то, доходит ли трафик по сети. Закрытый порт, маршрут, работающий только в одну сторону, неподходящий MTU или незаметно перезаписанные настройки DNS встречаются куда чаще, чем перепутанные ключи. Идти стоит по порядку: сначала смотрим состояние через wg show и tcpdump, затем проверяем связность, маршрутизацию, MTU и только в самом конце DNS.

Половина этого списка вообще не появляется, когда сеть на стороне сервера с самого начала настроена предсказуемо. VPS с отдельным публичным IPv4-адресом, полным доступом root и без лишнего файрвола провайдера перед UDP-портом даёт WireGuard ровно те условия, в которых он работает без сюрпризов.

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