Android OpenVPN: додати приватний маршрут без root на телефоні

Вам потрібна ще одна приватна підмережа — скажімо, 10.60.0.0/24, — якої в профілі зараз немає. На ноутбуці ви додали б маршрут і пішли далі. В Android VPN — це застосунок, пристрій tun належить цьому застосунку, і без root таблиці маршрутизації для правки немає. Маршрут усе одно має існувати, але він потрапляє в профіль, який завантажує клієнт, і працює лише тоді, коли інша сторона згодна. Далі — правка, перепідключення, бік сервера й відкат.

До правки: що маршрут може і чого не може

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

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

Правте той профіль, який клієнт справді завантажує

Для сумісного клієнта, який імпортує звичайний текст опцій OpenVPN, додавання — один рядок:

route 10.60.0.0 255.255.255.0

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

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

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

Перепідключіться і перевірте на пристрої

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

Перевіряйте адресата за адресою, а не за іменем. Перевірка TCP на один відомий порт служби говорить більше, ніж ping, бо багато хостів відповідають на ICMP, тоді як порт служби фільтрується. Якщо адреса відповідає, а ім'я ні, у вас питання до resolver, а не до маршрутизації, і наступний розділ не для вас.

Сюди ж належать дві перевірки області дії. VPN на застосунок означає, що адресний маршрут може бути, тоді як застосунок, яким ви тестуєте, перебуває поза включеним набором, тож тестуйте застосунком, який справді всередині. А префікс IPv4 нічого не каже про шлях IPv6; якщо служба dual-stack, додайте відповідний маршрут IPv6 або очікуйте, що клієнт віддасть перевагу шляху, якого ви не задумували.

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

Завершіть шлях на сервері

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

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

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

Відкат і приймання

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

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

• До будь-якої правки переконайтеся, що власник мережі дозволяє адресата.
• Помістіть маршрут у профіль, який завантажує клієнт, потім імпортуйте заново і перепідключіться.
• Перевіряйте через порт служби, всередині області на застосунок, для потрібної родини адрес.
• Виправляйте пересилання, зворотну маршрутизацію та iroute на сервері, а не на телефоні.
• Тримайте копію для відкату і перевірте знову після перезавантаження.