Android OpenVPN neprideda maršruto be tunelio adreso

Jūsų Android OpenVPN profilis neprideda maršruto, nes telefonas neturi adreso virtualiajame sąsajoje, todėl nėra ko maršrutui rodyti. Maršrutai atsako tik į tai, kur turi eiti paketai. Tunelio adresas atsako, kas yra telefonas tunelio viduje, ir klientas turi jį pateikti prieš atsirandant sąsajai. Pereikite keturias patikras žemiau iš eilės ir sustokite ties pirmu nepavykimu, nes maršrutų keitimas prieš atsirandant adresui paslepia tikrąją problemą.

Skaitykite klaidą ta tvarka, kuria ją vykdo klientas

Android VpnService.Builder laiko abi sąvokas atskirai: addAddress() įdeda adresą į sąsają, kurią stato programa, addRoute() prideda paskirties prefiksą, o establish() atsisako kurti sąsają, kol nepridėtas bent vienas adresas. OpenVPN klientas susieja profilį ir serverio siunčiamas parinktis būtent su tais iškvietimais, todėl ryšys, kuris niekada neanalizuoja adreso, negali apskritai sukurti sąsajos.

Štai kodėl žurnalo eilutė, kurią skaitote, gali minėti maršrutą, nors priežastis yra vienu žingsniu anksčiau. Klientas pasiekia maršruto etapą tik tada, kai sąsaja jau yra; be adreso maršruto iškvietimas iš karto nepavyksta arba niekada neįvyksta. Kai žurnalas sako, kad negalima pridėti maršruto, pradėkite nuo adreso, o ne nuo maršruto sintaksės.

Patikra 1: ar serveris į atsakymą įdeda adresą?

Maršrutuojamoje OpenVPN paslaugoje adresas ateina iš serverio baseino arba paskyrimo kiekvienam klientui, o formą lemia topologija. OpenVPN 2.4 ar naujesniame serveryje paslauga su potinklio topologija atrodo taip:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Su tokia forma serveris siunčia kažką panašaus į ifconfig 10.8.0.6 255.255.255.0. Senesnis topology net30 diegimas vietoj to siunčia partnerio adresą, pavyzdžiui ifconfig 10.8.0.6 10.8.0.5, todėl profilis, perkeltas tarp dviejų modelių, gali atrodyti teisingai, nors neša neteisingą tinklo kaukę.

Kliento ryšio žurnale ieškokite siunčiamų parinkčių rinkinio. Jei jame visai nėra ifconfig eilutės, serveris niekada nesiuntė adreso arba klientas atmetė parinktį. Serveryje, kuris naudoja client-config-dir, failas, pavadintas pagal sertifikato common name, turi egzistuoti ir turėti paskyrimą:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Patikra 2: ar klientas išsaugo gautą adresą?

Per platus filtras yra antra dažna priežastis. pull-filter egzistuoja OpenVPN 2.4 ir naujesnėse versijose, o kai keli filtrai atitinka tą pačią parinktį, laimi paskutinis atitikęs, todėl gale paliktas catch-all pašalina adresą be klaidos:

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

Susiaurinkite filtrą iki parinkties, kurios tikrai norite atsikratyti, ir palikite adresą ramybėje:

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

Patarimas išjungti visus pull dažniausiai ateina iš žmogaus, kuris nori atsikratyti vieno vienintelio maršruto. route-nopull yra siauresnis jungiklis: jis išlaiko ifconfig ir kitas siunčiamas parinktis, bet atmeta siunčiamus maršrutus ir DHCP tipo parinktis. Naudokite jį, kai to tikrai norite, o adreso klausimą spręskite atskirai.

Patikra 3: ar adresą rašyti turite jūs?

Rankinis adresavimas yra teisėtas tik tada, kai operatorius perduoda jums reikšmę. Jei įvedate patys, ji turi būti iš VPN kliento potinklio, unikali tarp aktyvių sesijų ir atitikti topologiją, kurią vykdo serveris. Darbalaukio tilto ar nuotolinio LAN kompiuterio adreso kopijavimas nepavyksta abiem atvejais: telefonas reikalautų adreso, kuris jau yra kitur, o tinklų sietuvas neturėtų grįžimo kelio į jį.

Nuotolinio LAN prefiksas maršrute yra paskirtis, niekada telefono tapatybė. Maršrutas 10.60.0.0/24 sako, kad į tą tinklą pateksite per tunelį; jis nieko nesako apie tai, kokį 10.60.0.x adresą telefonas turėtų turėti, ir telefonas neturėtų turėti nė vieno jų. Statiški paskyrimai priklauso serverio pusei, kur jie negali susidurti su dinaminiu baseinu.

Dvi sesijos vienu tapatumu atskleidžia tą patį susidūrimą. Jei tas pats sertifikatas prisijungia du kartus ir serveris siunčia vieną fiksuotą adresą abiem, antroji sesija dubliuoja pirmąją, o sprendimas yra atskiri tapatumai arba atskiri paskyrimai, o ne kliento pusės keitimas.

Patikra 4: ar kas nors kitas užima tunelio vietą?

Android leidžia vienu metu tik vieną aktyvią VPN paslaugą. Kita VPN programa arba visada įjungto VPN įrašas, paliktas įjungtas profiliui, kuris nebeveikia, gali užimti tą vietą prieš jūsų OpenVPN klientui iškviečiant establish(). Tada sąsaja niekada nepasirodo, nors profilis galioja, todėl atjunkite kitą VPN, išjunkite visada įjungto nustatymą ir prisijunkite iš naujo prieš liesdami profilį.

Paslauga, kuri reikalauja Ethernet tiltinimo, yra kita aklavietė. Android programa be root gali sukurti IP tunelį, o ne tiltu sujungtą Ethernet segmentą, todėl joks įvestas adresas neprivers dev tap serverio veikti; operatorius turi pasiūlyti maršrutuojamą paslaugą. Kai pranešate apie problemą, nurodykite kliento pavadinimą ir versiją, siunčiamų parinkčių rinkinį, topologiją ir tikslų žingsnį, kuriame adresas turėjo pasirodyti.

Jei visos keturios patikros praeina ir adresas yra, unikalus bei teisingai maskuotas, maršruto klausimas tampa įprastas: kokius prefiksus serveris leidžia ir kaip klientas turėtų juos apriboti. Užsirašykite tunelio adresą, jo tinklo kaukę ir topologiją prieš ką nors kita keisdami, nes būtent šias tris reikšmes operatoriui reikia palyginti su serverio vaizdu.