Proton VPN на Pi без екрана: застосунок чи файл WireGuard?

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

Питання архітектури йде першим, бо 64-бітна плата може виконувати 32-бітний простір користувача, а застосунок постачається лише з одним із них.

Дві межі підтримки, а не два інсталятори

Прочитайте поточну сторінку встановлення постачальника для потрібного застосунку і зіставте її з платою: випуск дистрибутива, архітектура пакета й будь-які вимоги до робочого столу або сеансу. Те, що Pi підтримує 64-бітну роботу, не говорить, який простір користувача встановлено зараз, і саме це значення перевіряє менеджер пакетів. dpkg --print-architecture і uname -m відповідають на це по одному рядку кожен. Якщо випуск або архітектура виходять за межі задокументованого набору, застосунок там не підтримується, навіть коли встановлюється.

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

Що застосунок дає, а профіль ні

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

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

WireGuard вручну: важливі кроки

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

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

Вирішіть, чи Pi також є шлюзом

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

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

Міф, від якого варто відмовитися, — що інсталятор Linux і файл WireGuard означають одне й те саме рішення. Це дві моделі роботи з двома різними власниками.