WireGuard не може створити свій інтерфейс: ядро чи права?
Створення інтерфейсу зривається ще до першого рукостискання з партнером. Прочитайте помилку, щоб відрізнити відсутній модуль від межі прав або від наявного власника інтерфейсу.
WireGuard не може створити свій інтерфейс, тому немає пристрою для налаштування, немає ключа для обміну й немає рукостискання для налагодження. Збій повністю залишається на локальній машині, і текст помилки каже, яка частина локального стека відмовила. Правильно прочитати його швидше, ніж перевстановити конфігурацію партнера. Шари можна розділити, і повідомлення називає той, що відмовив.
Помилка виникає до того, як заговорить будь-який партнер
Створення інтерфейсу — це один запит netlink до ядра про пристрій типу wireguard. Ядро або має драйвер, що розуміє цей тип, або не має, і відповідь повертається одразу. На цьому кроці жоден пакет не залишає машину, тому адреси кінцевих точок і ключі сервера не можуть бути причиною.
Цей порядок важливий для діагностики. Якщо команда так і не створила пристрій, проблема не може бути в неправильному відкритому ключі або заблокованому порту UDP. Спершу виправте локальний шлях створення і лише потім дивіться назовні.
Яка реалізація має володіти пристроєм
На цей запит можуть відповісти дві реалізації. Модуль усередині ядра реєструє тип пристрою wireguard, а реалізація в просторі користувача, наприклад wireguard-go, надає той самий інтерфейс іншим механізмом. Якщо модуль відсутній, ядро відхиляє запит з помилкою про непідтримуваний пристрій, і рішення — або завантажити модуль, або спрямувати інструменти на реалізацію в просторі користувача.
Перш ніж вибирати між ними, перевірте, що насправді присутнє. Перша команда показує, чи завантажено модуль, а друга запитує ядро безпосередньо:
lsmod | grep wireguard
ip link add wgtest0 type wireguardДруга команда — це найменше можливе відтворення: вона просить пристрій і більше нічого. Якщо вона зривається з повідомленням про непідтримуваний тип, відсутня частина — це реалізація, а не ваш файл конфігурації.
| Error text | What refused | Next step |
|---|---|---|
| Unknown device type or operation not supported | The kernel has no wireguard driver | Load the module or use the userspace implementation |
| Operation not permitted | Missing privilege | Use the service context or grant the capability |
| File exists | The name is already in use | Inspect the owner before touching it |
| No such device in a container | No tunnel device or capability | Add the device and NET_ADMIN to the container |
Права та межі контейнера
Створення й налаштування мережевого пристрою потребує прав: або як root, або з можливістю адмініструвати мережу. Звичайна сесія користувача цього не може, і це обмеження — сам задум, а не перешкода, яку слід обходити запуском неперевіреного інсталятора.
Усередині контейнера межа подвоюється. Контейнеру потрібен доступ до тунельного пристрою й можливість його налаштовувати, і прапорці, що це дають, ті самі, які використовує контейнер VPN у Linux. Обмежений гість, який зазвичай може переглядати веб, усе одно не може створити інтерфейс, бо перегляду така можливість не потрібна. Дайте можливість тій службі, якій вона потрібна, а не кожній сесії на хості.
Усуньте конфлікт імен і повторіть спробу
Інтерфейс, який уже існує, не обов'язково залишок. Інший менеджер може володіти іменем і використовувати його просто зараз, тому огляньте його, перш ніж щось видаляти:
ip link show wg0
sudo wg show wg0Якщо власником є активна служба, налаштуйте цю службу замість створення другого пристрою. Якщо він справді застарілий, видаліть його через інструмент, який його створив, і потім підніміть інтерфейс документованим клієнтом або юнітом, щоб конфігурація й пристрій залишалися узгодженими.
Щойно створення вдається, наступний збій належить пізнішому етапу, і юніт, що повідомляє про збій після появи пристрою, — це інша проблема, ніж пристрій, який так і не було створено. Розділіть ці два випадки, перш ніж знову змінювати права.