OpenVPN на Android не додає маршрут без адреси тунелю

Ваш профіль OpenVPN на Android не додає маршрут, бо телефон не має адреси на віртуальному інтерфейсі, тож маршруту нема на що вказувати. Маршрути відповідають лише на питання, куди мають іти пакети. Адреса тунелю відповідає на питання, ким є телефон усередині тунелю, і клієнт мусить надати її перш ніж інтерфейс зможе зявитися. Пройдіть чотири перевірки нижче по порядку й зупиніться на першому збої, бо виправлення маршрутів до появи адреси приховує справжню проблему.

Читайте збій у тому порядку, у якому його виконує клієнт

VpnService.Builder в Android розділяє два поняття: addAddress() ставить адресу на інтерфейс, який будує застосунок, addRoute() додає префікс призначення, а establish() відмовляється створювати інтерфейс, доки не додано бодай одну адресу. Клієнт OpenVPN відображає профіль і параметри, які надсилає сервер, саме на ці виклики, тож зєднання, яке жодного разу не розібрало адресу, взагалі не може побудувати інтерфейс.

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

Перевірка 1: чи вставляє сервер адресу у відповідь?

У маршрутизованій службі OpenVPN адреса береться з пулу сервера або з призначення для кожного клієнта, а форму задає топологія. На сервері OpenVPN 2.4 або новішому служба з топологією підмережі виглядає так:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

За такої форми сервер надсилає щось на кшталт ifconfig 10.8.0.6 255.255.255.0. Старіше встановлення з topology net30 надсилає натомість адресу партнера, наприклад ifconfig 10.8.0.6 10.8.0.5, тож профіль, перенесений між двома моделями, може виглядати правильним, але нести неправильну маску мережі.

Пошукайте в журналі зєднання клієнта набір надісланих параметрів. Якщо в ньому немає жодного рядка ifconfig, сервер ніколи не надсилав адресу або клієнт відхилив параметр. На сервері, який використовує client-config-dir, файл, названий за common name сертифіката, має існувати й містити призначення:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Перевірка 2: чи зберігає клієнт отриману адресу?

Занадто широкий фільтр — друга поширена причина. pull-filter існує в OpenVPN 2.4 і новіших, і коли кілька фільтрів збігаються з тим самим параметром, перемагає останній збіжний, тож catch-all у кінці прибирає адресу без помилки:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

Звузьте фільтр до того параметра, який справді треба прибрати, і залиште адресу в спокої:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

Порада вимкнути всі pull зазвичай походить від того, хто хоче позбутися одного єдиного маршруту. route-nopull — вужчий перемикач: він зберігає ifconfig та інші надіслані параметри, але відхиляє надіслані маршрути й параметри на кшталт DHCP. Використовуйте його, коли це справді те, що потрібно, а питання адреси вирішуйте окремо.

Перевірка 3: чи вам вписувати цю адресу?

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

Префікс віддаленої локальної мережі в маршруті — це призначення, а не особистість телефона. Маршрут для 10.60.0.0/24 каже, що до цієї мережі треба дістатися через тунель; він нічого не каже про те, яку адресу 10.60.0.x має мати телефон, і телефон не повинен мати жодної з них. Статичні призначення належать стороні сервера, де вони не можуть конфліктувати з динамічним пулом.

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

Перевірка 4: чи не зайняте місце тунелю чимось іншим?

Android дозволяє лише одну активну службу VPN одночасно. Інший застосунок VPN або запис постійно ввімкненого VPN, залишений увімкненим для профілю, який більше не працює, може зайняти це місце перш ніж ваш клієнт OpenVPN викличе establish(). Тоді інтерфейс не зявляється зовсім, хоча профіль коректний, тож відключіть інший VPN, вимкніть налаштування постійного ввімкнення й підключіться знову, перш ніж торкатися профілю.

Служба, яка наполягає на мості Ethernet, — це другий глухий кут. Застосунок Android без root може створити IP-тунель, а не мостовий сегмент Ethernet, тож жодна вписана адреса не змусить сервер dev tap працювати; оператор має запропонувати маршрутизовану службу. Коли повідомляєте про проблему, вкажіть імя та версію клієнта, набір надісланих параметрів, топологію й точний крок, на якому адреса мала зявитися.

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