VPN-сервер на Android: root не робить телефон доступним
Три окремі проблеми вирішують, чи може телефон обслуговувати клієнтів VPN: вхідний шлях, модель привілеїв і пересилання. root торкається лише середньої.
root змінює, які мережеві операції процес може спробувати. Він не дає телефону публічно доступну адресу, не резервує вхідне відображення в оператора і не тримає демон живим після перезавантаження. Якщо ви вирішуєте, чи може телефон Android виступати як VPN-сервер, розділіть три питання: чи може передбачуваний клієнт узагалі дістатися до слухача, яка модель привілеїв потрібна реалізації сервера і що треба пересилати, коли тунель піднято.
Хто і звідки має дістатися до телефона
Клієнт у тій самій дозволеній локальній мережі і клієнт на мобільних даних перевіряють дві різні мережі. Спершу визначтеся з передбачуваною, бо відповіді не переносяться. У Wi-Fi незапитаному вхідному трафіку зазвичай потрібне відображення на вищому маршрутизаторі й придатний публічний шлях за ним. У стільниковій мережі NAT операторського рівня означає, що вхідний IPv4 часто недоступний, хоч би що дозволяв телефон.
Саме цього останнього пункту root не може торкнутися. Локальний міжмережевий екран телефона і NAT оператора — різні системи, і зміна першого не впливає на другий. Приватна адреса інтерфейсу, значок мобільних даних або слухаючий сокет не є доказом доступності. Якщо шлях через оператора все ж пропонує глобально маршрутизований IPv6, для нього все одно потрібна усвідомлена політика слухача й міжмережевого екрана; мати адресу — не те саме, що приймати з'єднання.
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
Обслуговування і пересилання — два різні успіхи
Завершене рукостискання VPN доводить, що тунель існує. Воно не доводить, що клієнт дістанеться до локальної мережі за телефоном, і не доводить, що телефон може служити виходом в інтернет. Це окремі конфігурації, побудовані на внутрішньому плані адрес, маршрутах, поведінці при поверненні й вузько окресленій політиці пересилання для завдання, яке вам справді потрібне.
Режим відмови передбачуваний: рукостискання проходить, клієнт показує підключення, і нічого не завантажується. Перш ніж налагоджувати клієнт, вирішіть, яку з двох ролей ви будуєте. Віддалений доступ до пристрою в мережі телефона і вихід в інтернет через повний тунель вимагають різних правил пересилання, а надання обох, коли ви хотіли одного, розширює поверхню впливу, не додаючи запитаної можливості.
Модель привілеїв — це вибір, а не root або нічого
Звичайний демон OpenVPN, що використовує пристрій TUN ядра, потребує відповідних можливостей, доступу до вузла пристрою й співпраці політики безпеки Android. root не є всеохопним винятком із SELinux; привілейований процес усе одно обмежений політикою платформи. Тому двійковий файл, що спокійно працює на сервері Linux, може зазнати невдачі на телефоні без явної помилки про дозволи.
Реалізація шлюзу в просторі користувача може мати зовсім іншу модель привілеїв, тож поширене твердження, що кожному VPN-серверу на Android потрібен root, надто широке. root дає вам можливість пробувати більше операцій, а не гарантію, що їх дозволять або що результат буде доступним.
Власна реєстрація VPN-служби Android — ще один окремий механізм. Вона дає застосунку керований клієнтський інтерфейс з визначеним життєвим циклом; це не універсальний інсталятор сервера, і запуск демона з термінала не дає йому постійного керування, політики для окремих застосунків або власного шляху відновлення.
Якщо потрібна точка виходу, змініть архітектуру
Коли мета — просто віддалений вихід в інтернет через телефон, а не сумісність із наявним профілем OpenVPN, краще підходить підтримуваний вихідний вузол в оверлейній мережі. Tailscale документує роль вихідного вузла Android з власними кроками реєстрації, авторизації та вибору клієнта.
Компроміс реальний, і про нього варто сказати прямо: ви приймаєте інший протокол, іншу модель довіри й залежність від того облікового запису та служби координації. Це не змушує незмінений клієнт OpenVPN приєднатися до оверлейної мережі й не дає вам слухача OpenVPN на публічній адресі.
Що ще потрібно розгортанню
Який би шлях ви не обрали, операційні основи вирішують, чи протримається це тиждень. Тримайте облікові дані сервера приватними, видавайте різні ідентичності клієнтів і плануйте відкликання до того, як воно знадобиться. Вирішіть, як надходять оновлення, що підтримує роботу служби у фоні та як вона відновлюється після перезавантаження або зміни мережі.
Уникайте скорочень, які виглядають зручними: застарілий статичний двійковий файл, жорстко закодовані назви інтерфейсів і стартовий скрипт, що очищає наявну політику міжмережевого екрана. Потім приймайте результат лише за конкретним тестом: авторизований віддалений клієнт досягає потрібного ресурсу, заборонені призначення залишаються недоступними, а пристрій сам повертається після підтримуваної події життєвого циклу. Доступ root — один із можливих складників цього результату й рідко вирішальний.