Інтерфейс піднято, але wg-quick завершився помилкою: що робити далі

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

Частковий стан — це звичайний збій

Такої поведінки варто очікувати, а не вважати її пошкодженням. Інтерфейс — найдешевша частина налаштування і найпростіша для того, щоб залишитися після нього, і саме він змушує машину виглядати напівпрацездатною.

Чого ще немає — це все, що йшло після невдалого кроку. Якщо збій стався на етапі розпізнавача, адреси й маршрути є, а 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

Рукостискання без відповіді все одно каже, що тунель сформувався, а далекий бік мовчить, і це інша проблема, ніж юніт, який так і не запустився. Тримайте стан юніта, рукостискання і результат запиту в одному записі, бо вони збійно завершуються незалежно і лише їхнє поєднання описує систему.