WireGuard не запускается после перезагрузки: службы

WireGuard не запускается после перезагрузки: службы

Ryan Foster
11 октября 2026 г.· 10 мин чтения

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

Ключевые выводы:

  • Сохраняйте консоль провайдера, независимую от исправляемого туннеля.
  • Enabled описывает автозапуск, active — текущее состояние службы.
  • Рабочий unit с неработающим трафиком требует другой ветки диагностики.

С чего начать, если WireGuard не запускается после перезагрузки?

Процедура относится к Ubuntu 24.04 LTS, инструментам WireGuard дистрибутива и нативной службе wg-quick@wg0. Она основана на официальных документах без полного сквозного авторского тестирования. Приведённые признаки ожидаются при вашей проверке, а не получены автором экспериментально. Обзор обслуживания собственной сети разделяет владение хостом и клиентские настройки.

Нужны sudo и проверенная консоль провайдера либо другой административный путь вне wg0. Запишите время инцидента, ожидаемый интерфейс, последнюю успешную загрузку и последующие изменения пакетов или конфигурации. Не перезагружайте общий хост многократно и не останавливайте посторонние службы. Без доступной консоли восстановления остановитесь до операций, способных заменить единственный маршрут управления.

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

Шаг 1: Какое состояние показывает служба wg-quick systemd?

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

sudo systemctl is-enabled wg-quick@wg0
sudo systemctl is-active wg-quick@wg0
sudo systemctl is-failed wg-quick@wg0
sudo systemctl status --no-pager wg-quick@wg0
ip -brief link show wg0
sudo wg show interfaces

Сравните имя unit с фактическим интерфейсом. wg-quick@home0 читает другой файл, чем wg-quick@wg0; правильно включённый неправильный экземпляр не поднимет нужный интерфейс. Ubuntu связывает управление жизненным циклом с именем экземпляра.[1]

НаблюдениеЗначениеСледующее действие
Disabled и inactiveАвтозапуск экземпляра не настроенПодтвердить владельца перед включением
Enabled и failedЗапуск был запрошен, настройка завершилась ошибкойНайти первую значимую ошибку этой загрузки
Enabled и active, интерфейс естьЖизненный цикл может быть исправенПроверить пиры, затем маршруты и приложения
Active (exited), интерфейс естьOneshot может сохранять active после завершения настройкиПроверить тип unit и интерфейс, не ждать постоянного PID
Интерфейс есть, unit inactiveВладельцем может быть другой процесс или ручной запускСогласовать управление до второго менеджера

Type=oneshot вместе с RemainAfterExit=yes позволяет systemd показывать active после завершения команды настройки. Для Linux WireGuard не нужен постоянно работающий процесс wg-quick. Однако один статус active не подтверждает правильность всей требуемой сети.[2]

Шаг 2: Найдите первый отказ и фактического владельца

Прочитайте журнал неудачной загрузки и unit дистрибутива вместе с локальными переопределениями:

sudo journalctl -b -u wg-quick@wg0 --no-pager -n 100
sudo systemctl cat wg-quick@wg0
sudo systemctl show wg-quick@wg0 -p FragmentPath -p DropInPaths -p Type -p RemainAfterExit

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

Найдите первую неудачную команду вызова: отсутствующий файл, неверный ключ, конфликт адресов, недоступный helper, ошибка DNS или PostUp. Поздние ошибки очистки могут быть следствием. Запишите точное имя unit и категорию отказа, не публикуя учётные данные, попавшие в хуки.

Подтвердите владельца интерфейса. Панель, NetworkManager, контейнер или ручной wg-quick up могут конфликтовать с нативной службой. Не останавливайте другого менеджера наугад. Если он назначен владельцем намеренно, используйте его документацию. После переезда с изменением хоста или имени интерфейса сначала согласуйте миграционный реестр конфигурации, затем редактируйте unit.

Шаг 3: Проверьте сохранение конфигурации WireGuard и зависимости

Этот экземпляр ожидает /etc/wireguard/wg0.conf. Проверьте метаданные файла и каталога, не выводя секретное содержимое:

sudo stat -c '%U:%G %a %n' /etc/wireguard /etc/wireguard/wg0.conf
sudo test -s /etc/wireguard/wg0.conf
command -v wg
command -v wg-quick
command -v resolvectl

Используйте владельца root и ограничительные режимы: 0700 для каталога и 0600 для файла, если независимо проверенная политика управления не требует другого. Отсутствующий или пустой файл восстанавливают из доверенной копии; изменение прав не создаст его содержимое. До редактирования сохраните исходный файл под уникальным защищённым именем.

Откройте файл через sudoedit из доверенной консоли. Проверьте имя интерфейса, текущий адрес, формат ключа, открытые ключи пиров и хуки. Закрытый ключ должен быть действительным локально созданным значением, не заполнителем из примера. Не генерируйте новый серверный ключ как универсальное средство ремонта: придётся согласованно менять идентичность у клиентов.[3]

Проверьте SaveConfig: при true остановка могла заменить файловые правки работающими настройками. Согласуйте ожидаемый файл с последним доверенным реестром до перехода на файловое управление без параметра либо с false. Резервная копия может предшествовать отзывам; удалите эти идентичности до возврата службы.[3]

Может ли DNS или хук помешать запуску?

Для доменного Endpoint при настройке нужен работающий резолвер. Исследуйте службу разрешения имён хоста и запрашивайте только свой разрешённый Endpoint обычным локальным средством, например getent ahosts YOUR_ENDPOINT_NAME. Сравните ответ с ожидаемым: успешное разрешение случайного публичного имени мало говорит об этой зависимости. Объяснение разрешения Endpoint отделяет начальное разрешение от последующего перемещения пира.

Ubuntu обычно использует systemd-resolved, тогда как DNS= в wg-quick требует resolvconf и не настраивает resolved автоматически. Проверьте фактический механизм файла. Ubuntu документирует вариант с resolvectl-хуками и отдельно проверяемой политикой интерфейса. Не добавляйте вместе DNS= и несколько конкурирующих менеджеров, не подавляйте ошибку хука безусловным успехом.[1][3]

Порядок запуска помогает установленной зависимости, но network-online.target не гарантирует доступность каждого DNS-сервиса и удалённого Endpoint. До узкого override изучите unit дистрибутива и реальный механизм wait-online. Не маскируйте зависимости, не добавляйте бесконечные циклы ожидания, не отключайте межсетевой экран и не удаляйте все маршруты ради исчезновения красного статуса.

Шаг 4: Исправьте минимальную причину и запустите один раз

Выберите действие по доказательству. Отключённый, но исправный экземпляр можно включить после подтверждения владельца. Отсутствующий файл восстанавливайте из доверенной копии с актуальными отзывами. Для плохого хука исправьте helper или синтаксис; для неправильного override измените только его. Ротация ключей не исправляет определение unit.

После изменения unit или drop-in перечитайте определения systemd; для одной правки конфигурации daemon-reload не нужен. Затем один раз запустите неактивный интерфейс контролируемо:

sudo systemctl daemon-reload
sudo systemctl start wg-quick@wg0
sudo systemctl is-active wg-quick@wg0
sudo wg show wg0 latest-handshakes

Первая строка относится только к ветке изменения unit. Для уже активной службы этот блок не заменяет выбор между reload пиров и запланированным restart. Ошибка запуска возвращает вас к новому журналу, а не к повторным перезапускам.

После успешного ручного запуска и проверки приложения при необходимости задайте автозапуск:

sudo systemctl enable wg-quick@wg0
sudo systemctl is-enabled wg-quick@wg0

enable настраивает будущую активацию, но не доказывает работу ранее отказавшей службы. Сохраните исходное состояние включения для отката. Очистка метки failed также не исправляет неудачную команду.[1][2]

Шаг 5: Как проверить разрешённую перезагрузку?

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

Метод проверкиОжидаемый признакДействие при ошибке
Прочитать enabled, active и интерфейс перед загрузкойНужный владелец запускает нужный интерфейсСначала устранить конфликт или отказ
Перезагрузить в разрешённом окне, проверить тот же unitИнтерфейс появился, ошибок настройки нетИз консоли исследовать journal этой загрузки
Разрешённый клиент создаёт нужный запросСвежее рукопожатие и ответ службыРазделить причины ключа, Endpoint и пересылки
Повторно проверить файл и отозванных пировНастройки сохранены, старые идентичности не вернулисьПроверить SaveConfig или внешнего писателя
Повторить независимый доступ управленияПуть восстановления работаетПрекратить приёмку и вернуть управление

Когда wg0 исправен, проверяйте только заявленный охват трафика. Для интернет-выхода проверьте публичный адрес клиента, а DNS, IPv6 и отключение туннеля — отдельно. Частный split tunnel не требует смены браузерного IP. Успешная загрузка не создаёт политику блокирования трафика сама по себе.

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

Шаг 6: Восстановите последнюю доверенную конфигурацию запуска

При регрессии используйте независимую консоль. При необходимости остановите только этот unit, восстановите конкретно изменённый файл или drop-in из защищённой копии, повторно примените поздние отзывы и верните записанного владельца и права. daemon-reload нужен только при восстановлении определения unit. Верните прежний автозапуск по ситуации, выполните один start и повторите проверки.

При активной политике SaveConfig остановка может перезаписать отредактированный файл. Восстанавливайте доверенный файл после stop и согласуйте политику до следующего запуска. Не удаляйте vendor-unit, чужие drop-in, все правила межсетевого экрана или весь хост ради отката одного изменения. Если первое восстановление не удалось, сохраните ошибку и оставьте службу недоступной вместо широкого открытия доступа.

Похожее разделение бинарного файла, конфигурации и владельца unit важно для обновления Xray с откатом, хотя команды другие. После восстановления оцените долгосрочные обязанности владельца собственного выхода, если зависимости загрузки стали основной нагрузкой.

Итоги

  • Перед ремонтом различайте disabled, failed и active.
  • Сохраняйте независимое управление и доверенные настройки с актуальными отзывами.
  • Проверяйте реальную разрешённую загрузку и приложение раздельно.

Часто задаваемые вопросы (FAQ)

Почему unit включён, но не работает?

Включение определяет будущую активацию, а не её успех. Прочитайте journal текущей загрузки и найдите отказавшую команду до изменения сетевых настроек.

Active (exited) означает ошибку?

Для oneshot с RemainAfterExit такое состояние может быть нормальным. Проверяйте определение unit, интерфейс и трафик пиров вместо ожидания постоянного процесса.

Нужно включать wg-quick@wg0 на каждом сервере?

Включайте только экземпляр, владеющий нужным интерфейсом. Панели, NetworkManager и контейнеры требуют собственной настройки жизненного цикла службы.

DNS может сломать запуск при правильном ключе?

Доменный Endpoint и resolver-хук могут отказать независимо от ключей. До ротации учётных данных изучите зависимость и её фактический механизм управления.

Daemon-reload применяет изменение файла пиров?

Он перечитывает определения systemd. Изменения пиров применяют соответствующим reload интерфейса, а адреса и хуки могут потребовать контролируемого restart.

Можно перезагружаться, пока служба не заработает?

Повторные загрузки не определяют отказавшее условие и мешают другим службам. Исправьте первую ошибку и проверьте одну разрешённую перезагрузку с консолью восстановления.

Что делать с отозванным пиром в восстановленной копии?

Удалите все позднее отозванные идентичности до применения файла. Синтаксически корректная старая копия не отменяет последующие решения о доступе.

Источники:

  1. Ubuntu — Common tasks in WireGuard VPN — https://ubuntu.com/server/docs/how-to/wireguard-vpn/common-tasks/
  2. Ubuntu Noble — systemd.service(5) — https://manpages.ubuntu.com/manpages/noble/man5/systemd.service.5.html
  3. Ubuntu Noble — wg-quick(8) — https://manpages.ubuntu.com/manpages/noble/man8/wg-quick.8.html

Sources checked 11 октября 2026 г.


Рекомендуемые статьи:

Начните бесплатный 3-дневный пробный период

Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.

*Только для новых пользователей. Один пробный период на пользователя.

WireGuard не запускается после перезагрузки: службы | AethoVPN