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, датотеката именувана по 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 клиентот, да биде единствена меѓу активните сесии и да одговара на топологијата што ја извршува серверот. Копирањето на адресата на десктоп мост или на домаќин на далечната LAN паѓа по двете основи: телефонот би барал адреса што веќе постои на друго место, а портата не би имала повратен пат до неа.

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

Две сесии на еден идентитет ја откриваат истата колизија. Ако истиот сертификат се поврзе двапати и серверот прати една фиксна адреса до двете, втората сесија ја дуплира првата, а решението се одделни идентитети или одделни доделувања, а не измена на страната на клиентот.

Проверка 4: дали нешто друго го држи местото на тунелот?

Android дозволува само една активна VPN услуга истовремено. Друга VPN апликација или запис за секогаш вклучен VPN оставен вклучен за профил што веќе не работи може да го заземе тоа место пред вашиот OpenVPN клиент да го повика establish(). Тогаш интерфејсот никогаш не се појавува иако профилот е валиден, па исклучете го другиот VPN, исклучете го поставувањето за секогаш вклучен и поврзете се повторно пред да го допрете профилот.

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

Ако сите четири проверки поминат и адресата е присутна, единствена и правилно маскирана, прашањето за маршрутата станува вообичаено: кои префикси ги овластува серверот и како клиентот треба да ги ограничи. Запишете ја адресата на тунелот, неговата мрежна маска и топологијата пред да промените нешто друго, бидејќи тие три вредности се она што на операторот му треба за споредба со погледот на серверот.