Начните бесплатный 3-дневный пробный период
Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.
*Только для новых пользователей. Один пробный период на пользователя.


Если WireGuard не запускается после перезагрузки, сначала исследуйте состояние запуска, а уже потом меняйте маршруты. Найдите нужный интерфейс и unit systemd, отличите отключённый автозапуск от отказа и исправьте первую значимую ошибку до следующего теста загрузки.
Ключевые выводы:
- Сохраняйте консоль провайдера, независимую от исправляемого туннеля.
- Enabled описывает автозапуск, active — текущее состояние службы.
- Рабочий unit с неработающим трафиком требует другой ветки диагностики.
Процедура относится к Ubuntu 24.04 LTS, инструментам WireGuard дистрибутива и нативной службе wg-quick@wg0. Она основана на официальных документах без полного сквозного авторского тестирования. Приведённые признаки ожидаются при вашей проверке, а не получены автором экспериментально. Обзор обслуживания собственной сети разделяет владение хостом и клиентские настройки.
Нужны sudo и проверенная консоль провайдера либо другой административный путь вне wg0. Запишите время инцидента, ожидаемый интерфейс, последнюю успешную загрузку и последующие изменения пакетов или конфигурации. Не перезагружайте общий хост многократно и не останавливайте посторонние службы. Без доступной консоли восстановления остановитесь до операций, способных заменить единственный маршрут управления.
Если wg0 существует и рукопожатия обновляются, но приложения не работают, используйте проверки маршрутов при соединении без интернета. Перезапуск исправной службы скроет различие и прервёт другие устройства. Сначала установите, отсутствует ли интерфейс, сорвалась ли настройка или отказал последующий сетевой слой.
На проблемном сервере выполняйте запросы по одному. Ненулевой код команды состояния требует интерпретации, а не немедленного перехода к следующему исправлению:
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]
Прочитайте журнал неудачной загрузки и 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.
Этот экземпляр ожидает /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]
Для доменного 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. Не маскируйте зависимости, не добавляйте бесконечные циклы ожидания, не отключайте межсетевой экран и не удаляйте все маршруты ради исчезновения красного статуса.
Выберите действие по доказательству. Отключённый, но исправный экземпляр можно включить после подтверждения владельца. Отсутствующий файл восстанавливайте из доверенной копии с актуальными отзывами. Для плохого хука исправьте 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]
Сначала подтвердите консоль восстановления, доверенную копию и текущее исправленное поведение. Если окно обслуживания не даёт права на перезагрузку, получите разрешение именно для этого хоста. Перезапуск контейнера не доказывает жизненный цикл загрузки всей машины.
| Метод проверки | Ожидаемый признак | Действие при ошибке |
|---|---|---|
| Прочитать enabled, active и интерфейс перед загрузкой | Нужный владелец запускает нужный интерфейс | Сначала устранить конфликт или отказ |
| Перезагрузить в разрешённом окне, проверить тот же unit | Интерфейс появился, ошибок настройки нет | Из консоли исследовать journal этой загрузки |
| Разрешённый клиент создаёт нужный запрос | Свежее рукопожатие и ответ службы | Разделить причины ключа, Endpoint и пересылки |
| Повторно проверить файл и отозванных пиров | Настройки сохранены, старые идентичности не вернулись | Проверить SaveConfig или внешнего писателя |
| Повторить независимый доступ управления | Путь восстановления работает | Прекратить приёмку и вернуть управление |
Когда wg0 исправен, проверяйте только заявленный охват трафика. Для интернет-выхода проверьте публичный адрес клиента, а DNS, IPv6 и отключение туннеля — отдельно. Частный split tunnel не требует смены браузерного IP. Успешная загрузка не создаёт политику блокирования трафика сама по себе.
Используйте проверку публичного IP через фактический путь клиентского приложения, не браузер сервера. Если рукопожатия вернулись, а трафик нет, переходите к маршрутизации, не отменяя корректное исправление запуска.
При регрессии используйте независимую консоль. При необходимости остановите только этот unit, восстановите конкретно изменённый файл или drop-in из защищённой копии, повторно примените поздние отзывы и верните записанного владельца и права. daemon-reload нужен только при восстановлении определения unit. Верните прежний автозапуск по ситуации, выполните один start и повторите проверки.
При активной политике SaveConfig остановка может перезаписать отредактированный файл. Восстанавливайте доверенный файл после stop и согласуйте политику до следующего запуска. Не удаляйте vendor-unit, чужие drop-in, все правила межсетевого экрана или весь хост ради отката одного изменения. Если первое восстановление не удалось, сохраните ошибку и оставьте службу недоступной вместо широкого открытия доступа.
Похожее разделение бинарного файла, конфигурации и владельца unit важно для обновления Xray с откатом, хотя команды другие. После восстановления оцените долгосрочные обязанности владельца собственного выхода, если зависимости загрузки стали основной нагрузкой.
Включение определяет будущую активацию, а не её успех. Прочитайте journal текущей загрузки и найдите отказавшую команду до изменения сетевых настроек.
Для oneshot с RemainAfterExit такое состояние может быть нормальным. Проверяйте определение unit, интерфейс и трафик пиров вместо ожидания постоянного процесса.
Включайте только экземпляр, владеющий нужным интерфейсом. Панели, NetworkManager и контейнеры требуют собственной настройки жизненного цикла службы.
Доменный Endpoint и resolver-хук могут отказать независимо от ключей. До ротации учётных данных изучите зависимость и её фактический механизм управления.
Он перечитывает определения systemd. Изменения пиров применяют соответствующим reload интерфейса, а адреса и хуки могут потребовать контролируемого restart.
Повторные загрузки не определяют отказавшее условие и мешают другим службам. Исправьте первую ошибку и проверьте одну разрешённую перезагрузку с консолью восстановления.
Удалите все позднее отозванные идентичности до применения файла. Синтаксически корректная старая копия не отменяет последующие решения о доступе.
Источники:
Sources checked 11 октября 2026 г.
Рекомендуемые статьи:
Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.
*Только для новых пользователей. Один пробный период на пользователя.