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

Частичное состояние — это обычный сбой

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

Чего ещё нет — это всё, что шло после неудачного шага. Если сбой произошёл на этапе распознавателя, адреса и маршруты есть, а DNS нет. Если это был маршрут, у туннеля есть адрес и нет никакого пути через него.

Следствие — машина, которая отвечает на одни проверки и проваливает другие, поэтому люди заключают, что служба мигает, хотя она ни разу не запустилась успешно. Служба, которая ни разу не завершилась, мигать не может. Она может только снова и снова сбоить по одной и той же причине.

Найдите первый неудачный шаг

Читайте журнал юнита, а не только текущий статус, и читайте его с начала неудачного запуска. Последняя строка сообщает код выхода; первая ошибка говорит, что чинить.

Эти команды печатают состояние юнита, журнал загрузки для этого юнита и живое состояние туннеля:

systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager | tail -40
wg show
ip -4 addr show dev wg0

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

Три условия, которые определяют починку

Решите, чистите ли вы, чините на месте или убираете юнит из пути загрузки, и решите это до того, как что-то напечатаете.

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

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

Почистите перед повторной попыткой

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

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

Докажите туннель, а не юнит

Зелёный юнит означает, что последовательность запуска завершилась с нулём. Это не значит, что пакет дошёл до другой стороны, и не значит, что распознаватель настроен так, как вы задумали.

Отправьте запрос через туннель и прочитайте состояние, которое его породило:

systemctl is-active wg-quick@wg0
wg show wg0 latest-handshakes
ping -c 3 10.63.0.1
resolvectl query internal.example.net

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

Похожие статьи