Портативний VPN-клієнт без прав адміністратора: що все ще ламається

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

Портативність охоплює три різні обіцянки, і лише одна з них безкоштовна

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

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

Знайдіть привілейованого помічника, якого викличе клієнт

Майже жоден VPN-клієнт не рухає пакети сам. У Windows шлях даних іде через фільтри WFP і Base Filtering Engine, у macOS — через постачальника NetworkExtension, якого користувач схвалює в Параметрах системи, а в Linux — через пристрій tun плюс стек маршрутизації. Скопійований вами двійковий файл — це поверхня керування для цих компонентів, а не їхня заміна. Запитайте, який компонент очікує клієнт, потім підтвердьте, що він встановлений, працює і доступний вашому обліковому запису.

Linux — найпростіше місце, щоб це довести, бо перевірка — один системний виклик. Відкрити /dev/net/tun і попросити в ядра пристрій вимагає CAP_NET_ADMIN, а документація ядра щодо TUN/TAP вказує і правило власності, і можливість. Запустіть перевірку від облікового запису, який запустить клієнт, а не від root.

ls -l /dev/net/tun
ip tuntap add dev vpntest mode tun
ip link delete vpntest

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

Перевірте зміни маршруту і резолвера до першого підключення

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

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

ip route add 10.20.0.0/16 dev vpntest
ip route del 10.20.0.0/16
resolvectl query intranet.example.internal

Якщо перший рядок повертає RTNETLINK answers: Operation not permitted, обліковий запис не може встановити приватний маршрут, якого потребує профіль. Другий рядок доводить те саме право у зворотному напрямку, і це важливо, бо клієнт, який уміє додавати маршрути, але не видаляти їх, залишає після себе зламану таблицю. Потім запит до резолвера показує, чи приватні імена розв'язуються через тунель, чи витікають до того резолвера, якому хост уже довіряє.

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

Вирішіть, що має пережити сеанс

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

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

ip -brief addr show
ip route show table main
resolvectl status

Усе, що присутнє в другому знімку і відсутнє в першому, потребує власника. Або клієнт видаляє це під час виходу, або ви видаляєте це тими самими командами, які його створили, і це видалення належить до нотаток про розгортання, а не до чиєїсь пам'яті про те, що сталося. У Windows еквівалентні читання — Get-NetAdapter, Get-NetRoute і Get-DnsClientServerAddress, вони не потребують підвищення прав, але показують ті самі залишки.