OpenVPN v Androidu ne doda poti brez naslova tunela

Vaš profil OpenVPN v Androidu ne doda poti, ker telefon nima naslova na navideznem vmesniku, zato ni ničesar, na kar bi pot lahko kazala. Poti odgovarjajo le na to, kam naj gredo paketi. Naslov tunela odgovarja na to, kdo je telefon znotraj tunela, in odjemalec ga mora zagotoviti, preden lahko vmesnik sploh nastane. Pojdite skozi štiri preveritve spodaj po vrsti in ustavite se pri prvi napaki, ker urejanje poti, preden naslov obstaja, skrije pravi problem.

Preberite napako v vrstnem redu, v katerem jo odjemalec izvede

VpnService.Builder v Androidu drži pojma ločena: addAddress() vstavi naslov na vmesnik, ki ga aplikacija gradi, addRoute() doda ciljno predpono, establish() pa zavrne ustvaritev vmesnika, dokler ni dodan vsaj en naslov. Odjemalec OpenVPN preslika profil in možnosti, ki jih pošilja strežnik, točno na te klice, zato povezava, ki nikoli ne razčleni naslova, vmesnika sploh ne more zgraditi.

Zato lahko vrstica dnevnika, ki jo berete, omenja pot, medtem ko je vzrok korak prej. Odjemalec doseže fazo poti šele po tem, ko vmesnik obstaja; brez naslova klic poti takoj spodleti ali pa se nikoli ne izvede. Ko dnevnik pravi, da poti ni mogoče dodati, začnite z naslovom in ne s skladnjo poti.

Preveritev 1: ali strežnik v odgovor vstavi naslov?

Pri usmerjeni storitvi OpenVPN naslov pride iz nabora strežnika ali iz dodelitve za vsakega odjemalca, obliko pa določi topologija. Na strežniku OpenVPN 2.4 ali novejšem je storitev s topologijo podomrežja videti takole:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

S to obliko strežnik pošlje nekaj takega kot ifconfig 10.8.0.6 255.255.255.0. Starejša namestitev z topology net30 namesto tega pošlje naslov partnerja, na primer ifconfig 10.8.0.6 10.8.0.5, zato je profil, prenesen med obema modeloma, lahko videti pravilen, čeprav nosi napačno omrežno masko.

V dnevniku povezave odjemalca poiščite nabor poslanih možnosti. Če v njem ni niti ene vrstice ifconfig, strežnik nikoli ni poslal naslova ali pa je odjemalec možnost zavrnil. Na strežniku, ki uporablja client-config-dir, mora datoteka, poimenovana po common name certifikata, obstajati in vsebovati dodelitev:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Preveritev 2: ali odjemalec ohrani prejeti naslov?

Prenesen filter je drugi pogost vzrok. pull-filter obstaja v OpenVPN 2.4 in novejšem, in ko se več filtrov ujema z isto možnostjo, zmaga zadnji ujemajoči se, zato catch-all na koncu odstrani naslov brez napake:

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

Zoženite filter na možnost, ki se je res želite znebiti, naslov pa pustite pri miru:

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

Nasvet, naj izklopite vse pull, običajno prihaja od nekoga, ki se želi znebiti ene same poti. route-nopull je ožje stikalo: ohrani ifconfig in druge poslane možnosti, medtem ko zavrača poslane poti in možnosti v slogu DHCP. Uporabite ga, ko je to res tisto, kar želite, vprašanje naslova pa rešite ločeno.

Preveritev 3: je naslov vaš za vnos?

Ročno naslavljanje je upravičeno le, ko vam operater izroči vrednost. Če naslov vnesete sami, mora priti iz podomrežja odjemalca VPN, biti edinstven med dejavnimi sejami in ustrezati topologiji, ki jo izvaja strežnik. Kopiranje naslova namiznega mostu ali gostitelja v oddaljenem LAN-u spodleti na obeh točkah: telefon bi zahteval naslov, ki že obstaja drugje, prehod pa ne bi imel poti nazaj do njega.

Predpona oddaljenega LAN-a v poti je cilj, nikoli identiteta telefona. Pot za 10.60.0.0/24 pravi, da do tega omrežja pridete skozi tunel; ne pove ničesar o tem, kateri naslov 10.60.0.x naj bi imel telefon, in telefon ne bi smel imeti nobenega od njih. Statične dodelitve pripadajo strani strežnika, kjer ne morejo trčiti v dinamični nabor.

Dve seji z eno identiteto razkrijeta isto trčenje. Če se isto potrdilo poveže dvakrat in strežnik pošlje en fiksni naslov obema, druga seja podvoji prvo, rešitev pa so ločene identitete ali ločene dodelitve, ne urejanje na strani odjemalca.

Preveritev 4: ali nekaj drugega zaseda mesto tunela?

Android dovoljuje samo eno dejavno storitev VPN hkrati. Druga aplikacija VPN ali vnos vedno vklopljenega VPN, ki je ostal vklopljen za profil, ki ne deluje več, lahko zasede to mesto, preden vaš odjemalec OpenVPN pokliče establish(). Vmesnik se potem nikoli ne pojavi, čeprav je profil veljaven, zato odklopite drugi VPN, izklopite nastavitev vedno vklopljenega in se znova povežite, preden se dotaknete profila.

Storitev, ki vztraja pri mostenju Ethernet, je druga slepa ulica. Aplikacija za Android brez root lahko ustvari tunel IP, ne mostenega segmenta Ethernet, zato noben naslov, ki ga vnesete, ne bo pognal strežnika dev tap; operater mora ponuditi usmerjeno storitev. Ko prijavljate težavo, navedite ime in različico odjemalca, poslani nabor možnosti, topologijo in točen korak, v katerem bi se moral naslov pojaviti.

Če vse štiri preveritve uspejo in je naslov prisoten, edinstven in pravilno maskiran, vprašanje poti postane običajno: katere predpone strežnik dovoljuje in kako naj jih odjemalec omeji. Zapišite naslov tunela, njegovo omrežno masko in topologijo, preden karkoli drugega spremenite, ker so te tri vrednosti tisto, kar mora operater primerjati s pogledom strežnika.