Ваш VPN працює лише після входу через зв'язку ключів

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

Чому вхід змушує це працювати

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

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

Вирішіть, який власник запускає тунель

Є два підтримувані шаблони, і їх змішування — інший спосіб, у який це ламається. NetworkManager може активувати з'єднання системного рівня, що доречно, коли машина вже централізує мережу там. Або окремий юніт systemd запускає VPN безпосередньо й сам володіє інтерфейсом.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

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

Покладіть секрет туди, де служба може його прочитати

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

Спокусливий короткий шлях — зробити файл читабельним для всіх, доки не зникне помилка прав. Це міняє відмову при завантаженні на довготривалий витік облікових даних, і це той вид зміни, до якого ніхто не повертається. Використовуйте механізм, якому розгортання вже довіряє: обмежений файл облікових даних, незашифрований ключ, захищений правами файлу, або з'єднання системного рівня з власним сховищем секретів.

Перевірте подію, яка справді відбувається

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

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

Порядок важливий не менше за облікові дані. Юніт, який стартує раніше, ніж налаштоване основне висхідне з'єднання, здасться, а деякі дистрибутиви різняться тим, чи чекають вони на зв'язність. Якщо юніт повідомляє про збій під час завантаження, але успішно запускається вручну через тридцять секунд, ви знайшли проблему порядку, а не проблему секрету.

Перевіряйте маршрути й DNS, а не лише інтерфейс

Наявний інтерфейс — не робочий тунель. Після неконтрольованого запуску перевірте маршрути, стан розв'язувача та одне призначення за адресою, перш ніж перевіряти ім'я. Потім перевірте застосунок, для якого існує тунель.

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

Якщо адреса працює, а ім'я ні, залишкова проблема — політика DNS, а не тунель. Запишіть, який власник запускає службу і де живе секрет, бо наступній людині, яка перезавантажить цю машину, знадобляться обидва факти.