Android OpenVPN не добавя маршрут без адрес на тунела

Профилът ви 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 файлът, именуван по общото име в сертификата, трябва да съществува и да съдържа назначението:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Проверка 2: запазва ли клиентът дадения му адрес?

Твърде широк филтър е втората честа причина. pull-filter съществува от OpenVPN 2.4 нататък и когато няколко филтъра съвпадат с една опция, печели последният, затова завършващ филтър, който хваща всичко, премахва адреса без грешка:

# 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 клиента, уникална сред активните сесии и съответстваща на топологията на сървъра. Копирането на адрес на настолен мост или на хост в отдалечената LAN се проваля по два пункта: телефонът ще поиска адрес, който вече съществува другаде, и шлюзът не би имал обратен път до него.

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

Две сесии на една самоличност показват същия сблъсък. Ако един и същ сертификат се свърже два пъти и сървърът изпрати един фиксиран адрес на двете, втората сесия дублира първата и решението са отделни самоличности или отделни назначения, а не промяна в клиента.

Проверка 4: не заема ли нещо друго мястото на тунела?

Android позволява само една активна VPN услуга наведнъж. Друго VPN приложение или запис always-on, оставен включен за профил, който вече не работи, може да заеме мястото, преди вашият OpenVPN клиент да извика establish(). Тогава интерфейсът никога не се появява, макар профилът да е валиден, затова прекъснете другия VPN, изключете always-on и се свържете отново, преди да пипате профила.

Услуга, която настоява на Ethernet мостове, е другата задънена улица. Приложение за Android без root може да създаде IP тунел, но не и мостиран Ethernet сегмент, затова нито един въведен адрес няма да накара сървър с dev tap да работи; операторът трябва да предложи маршрутизирана услуга. Когато докладвате проблема, добавете името и версията на клиента, набора от изпратени опции, топологията и точната стъпка, където адресът е трябвало да се появи.

Ако и четирите проверки минат и адресът е налице, уникален и правилно маскиран, въпросът за маршрута става обикновен: кои префикси разрешава сървърът и как клиентът трябва да ги ограничи. Запишете адреса на тунела, маската му и топологията, преди да промените друго, защото точно тези три стойности операторът сравнява със сървърния изглед.