WireGuard: не работает после перезагрузки — причины и решение

MAATRIX

Настроили туннель, всё работало, перезагрузили сервер — и связи нет: WireGuard не работает после перезагрузки. Это не поломка конфига, а типичная проблема с сохранением состояния: настройки, поднятые вручную, не переживают ребут, если их не закрепить. Причина почти всегда в одном из трёх: не включён автозапуск, форвардинг или NAT не сохранены, либо сбит порядок загрузки. Разберём, как сделать так, чтобы туннель поднимался сам.

Первое действие: проверьте, поднялся ли интерфейс

После перезагрузки первым делом посмотрите, существует ли вообще интерфейс WireGuard и запущен ли сервис. Это сразу показывает, в чём дело:

wg show
systemctl status wg-quick@wg0

Если wg show пуст, а интерфейса wg0 нет — туннель после ребута просто не поднялся, то есть не настроен автозапуск. Если сервис в состоянии inactive (dead) — то же самое: его никто не стартовал при загрузке. Если же интерфейс есть и handshake идёт, но интернета через VPN нет — туннель поднялся, а вот форвардинг или NAT не восстановились (сохранились только в памяти до ребута). Это ключевая развилка: либо не поднимается сам туннель, либо поднимается, но теряет сетевые настройки. Определив, какой из двух случаев ваш, вы сразу переходите к нужному решению и не тратите время впустую.

Причина 1: не включён автозапуск через systemd

Самая частая причина — вы поднимали туннель вручную командой wg-quick up wg0, и она, естественно, не выполняется сама после перезагрузки. Чтобы туннель стартовал автоматически при загрузке, нужно включить соответствующий сервис systemd. Это делается одной командой:

systemctl enable --now wg-quick@wg0

enable добавляет сервис в автозагрузку, а --now сразу его запускает. Теперь при каждой перезагрузке systemd сам поднимет туннель wg0 из конфига /etc/wireguard/wg0.conf. Проверить, что автозапуск включён, можно через systemctl is-enabled wg-quick@wg0 — ответ должен быть enabled. Это решает большинство случаев «после ребута ничего нет»: конфиг был в порядке, просто некому было его поднять. Ручной wg-quick up хорош для проверки, но для постоянной работы туннель обязательно оформляют как сервис автозагрузки. С включённым автозапуском интерфейс появляется сам сразу после старта системы.

Причина 2: форвардинг сбрасывается после ребута

Если туннель поднимается, но интернета через VPN после перезагрузки нет, частая причина — IP-форвардинг был включён только в памяти (sysctl -w) и сбросился при ребуте. Команда sysctl -w net.ipv4.ip_forward=1 действует до перезагрузки, а чтобы настройка сохранялась, её нужно записать в конфигурацию. Проверьте текущее состояние и закрепите значение:

sysctl net.ipv4.ip_forward
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

Если после ребута ip_forward снова стал 0 — значит, он не был сохранён в /etc/sysctl.conf (или файле в /etc/sysctl.d/). Запись в конфиг и sysctl -p делают настройку постоянной. Это классическая ошибка: при первичной настройке форвардинг включили командой на лету, VPN заработал, а про сохранение забыли — и первый же ребут «ломает» интернет через туннель. Закрепив форвардинг в конфиге, вы гарантируете, что после любой перезагрузки сервер снова готов пересылать трафик клиентов наружу без ручного вмешательства.

Причина 3: правила NAT не восстанавливаются

Аналогичная история с NAT-маскарадингом: если вы добавили правило iptables ... MASQUERADE вручную командой, оно живёт только до перезагрузки, а после ребута исчезает — и трафик клиентов перестаёт возвращаться, интернета через VPN снова нет. Правильное решение — привязать правило к самому туннелю через PostUp/PostDown в конфиге WireGuard, чтобы оно ставилось при каждом поднятии wg0:

PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Так правило NAT автоматически добавляется, когда туннель поднимается (в том числе при автозапуске после ребута), и убирается, когда опускается. Это надёжнее, чем сохранять iptables отдельно, потому что жизнь правила синхронизирована с жизнью туннеля. Уточните имя внешнего интерфейса (eth0 может быть иным — проверьте через ip route | grep default). Связав NAT с поднятием туннеля через PostUp, вы избавляетесь от необходимости восстанавливать правила руками после каждой перезагрузки — всё поднимается единым целым.

Причина 4: порядок загрузки и зависимости

Реже туннель не поднимается из-за проблем порядка загрузки: WireGuard стартует раньше, чем готова сеть, и падает, потому что внешний интерфейс или маршрут ещё не подняты. Обычно systemd справляется с зависимостями сам, но на нестандартных конфигурациях бывают сбои. Посмотрите лог загрузки сервиса, чтобы понять, не упал ли он на старте:

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

Если в логе видно, что сервис пытался подняться, но не нашёл интерфейс или маршрут — проблема в порядке. В таких случаях помогает добавление зависимости от готовности сети (например, чтобы сервис ждал network-online.target). Также убедитесь, что нужный модуль ядра загружается при старте (на KVM с современным ядром это не проблема, но на нестандартных системах модуль стоит внести в автозагрузку). Эти случаи редки, но если автозапуск включён, форвардинг и NAT закреплены, а туннель всё равно не встаёт после ребута — смотрите именно лог загрузки сервиса: он покажет, на каком этапе и почему старт не удался.

Как проверить, что всё переживает перезагрузку

Единственный честный способ убедиться, что проблема решена, — перезагрузить сервер и проверить всё после ребута без единого ручного действия. Перезагрузитесь и сразу проверьте туннель, форвардинг и выход в интернет:

reboot

После загрузки выполните wg show (интерфейс должен подняться сам), sysctl net.ipv4.ip_forward (должна быть 1) и с клиента проверьте доступ в интернет через VPN. Если всё работает без ручного вмешательства — значит, автозапуск, форвардинг и NAT закреплены корректно. Это финальная проверка, которую нельзя пропускать: настройки, работающие «сейчас», ничего не говорят о том, переживут ли они ребут. Только реальная перезагрузка подтверждает, что сервер восстанавливает VPN самостоятельно. Проведя её один раз после настройки, вы будете уверены, что случайный или плановый ребут не оставит вас без связи.

Профилактика: чтобы VPN всегда поднимался сам

Правило простое: всё, что вы настраиваете для WireGuard, должно быть закреплено так, чтобы переживать перезагрузку. Туннель — через автозапуск сервиса (systemctl enable wg-quick@wg0). Форвардинг — записью в /etc/sysctl.conf или /etc/sysctl.d/, а не разовой командой. NAT-маскарадинг — через PostUp/PostDown в конфиге, привязанные к поднятию туннеля. Тогда после любого ребута сервер сам собирает рабочий VPN из закреплённых настроек, а не ждёт вашего вмешательства.

Возьмите за привычку после первичной настройки любого сервиса делать контрольную перезагрузку и проверять, что всё поднялось само, — это ловит забытые «временные» команды до того, как они подведут в неподходящий момент. Держите под VPN сервер с полной виртуализацией KVM и современным ядром, где модуль WireGuard и автозагрузка работают без ограничений. Закреплённые настройки плюс проверочный ребут превращают «WireGuard не работает после перезагрузки» в решённый раз и навсегда вопрос: сервер перезагружается — и VPN просто снова здесь.

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