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

Это узнаваемый класс проблем, и все они об одном: порядок запуска. Туннель поднимается не сам по себе, а поверх подключения к провайдеру. Если к моменту его старта нижележащее подключение ещё не готово, попытка проваливается — а повторять её роутер иногда не начинает.

Ручное включение работает именно поэтому: к тому моменту всё, чего не хватало, уже на месте.

Причина 1. Туннель привязан к интерфейсу провайдера

Самая частая и самая быстро проверяемая.

В параметрах подключения WireGuard есть поле «Подключаться через». Если там выбран конкретный интерфейс — а не автоматический выбор, — туннель ждёт готовности именно этого интерфейса. При загрузке роутера тот ещё не поднят, и туннель уходит в ожидание.

Признак: в журнале строка вида interface is not ready, standby, после которой попыток больше нет. Ручное переключение поднимает туннель мгновенно.

Лечение: откройте параметры туннеля и снимите привязку в поле «Подключаться через», оставив автоматический выбор. На форуме Keenetic это решение повторяется из темы в тему: без привязки к основному интерфейсу туннель поднимается штатно.

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

Причина 2. Проверка доступности интернета задерживает подключение

Более коварный вариант: туннель поднимается, но с задержкой в несколько минут, и всё это время выглядит сломанным.

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

Признак: в журнале видна цепочка — сначала неудачная проверка, затем несколько минут неуспешных попыток разрешения имени, потом накопление успешных проверок и только после этого рукопожатие. Туннель в итоге встаёт сам, просто позже, чем вы успели решить, что он сломан.

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

Причина 3. В адресе сервера домен, а DNS на старте ещё не отвечает

Родственный случай, отличается точкой отказа.

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

Признак: в журнале не «интерфейс не готов», а неудачное разрешение имени. Через минуту-другую попытка проходит сама.

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

Причина 4. Туннель поднялся, но трафик идёт мимо

Отдельный симптом, который часто принимают за тот же самый: подключение в интерфейсе зелёное, рукопожатие есть, а сайты открываются с домашнего адреса.

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

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

Лечение: проверьте раздел приоритетов подключений и принадлежность устройств к нужной политике — как это устроено, разобрано в статье о выборочной маршрутизации на Keenetic.

Как отличить по журналу

Что в журнале Причина
interface is not ready, standby, дальше тишина привязка к интерфейсу
Неудачная проверка, потом накопление успешных Ping Check
Не разрешается имя сервера DNS на старте
Рукопожатие есть, счётчики стоят приоритеты подключений

Журнал роутера здесь важнее любых догадок: четыре причины дают четыре разные записи, и одного взгляда хватает, чтобы не перебирать настройки вслепую.

Проверка вместо догадок

Перезагрузите роутер и не трогайте его десять минут. Это главное — большинство диагнозов ставится неверно потому, что человек нажимает «включить» через минуту и тем самым стирает улику.

Дальше по результату:

  • туннель поднялся сам за несколько минут — это Ping Check или DNS, чинить нечего;
  • не поднялся вовсе, в журнале standby — снимайте привязку к интерфейсу;
  • поднялся, но трафик идёт напрямую — смотрите приоритеты подключений.

Коротко

Если туннель не встаёт после перезагрузки, но включается вручную, дело не в его настройках, а в том, что он стартует раньше, чем готово подключение под ним. Сначала снимите привязку в поле «Подключаться через» — это решает большинство случаев. Задержка в несколько минут вместо отказа означает проверку доступности интернета и лечения не требует. Домен в адресе сервера на IP не меняйте: задержку на старте он даёт разовую, а проблем при смене адреса сервера создаст куда больше. И отдельно проверьте, что поднявшийся туннель действительно назначен основным подключением — иначе он будет зелёным и бесполезным.