Androidi OpenVPN ei lisa marsruuti ilma tunneliaadressita

Teie Androidi OpenVPN profiil ei suuda marsruuti lisada, sest telefonil pole virtuaalliidesel ühtegi aadressi, seega pole midagi, millele marsruut saaks osutada. Marsruudid vastavad ainult sellele, kuhu paketid peaksid minema. Tunneliaadress vastab sellele, kes on telefon tunneli sees, ja klient peab selle esitama enne, kui liides saab üldse tekkida. Käige allolevad neli kontrolli järjekorras läbi ja peatuge esimese vea juures, sest marsruutide muutmine enne aadressi olemasolu varjab tegelikku probleemi.

Lugege viga selles järjekorras, milles klient selle täidab

Androidi VpnService.Builder hoiab need kaks mõistet lahus: addAddress() paneb aadressi liidesele, mida rakendus ehitab, addRoute() lisab sihtprefiksi ja establish() keeldub liidest loomast, kuni vähemalt üks aadress on lisatud. OpenVPN klient vastendab profiili ja serveri saadetud valikud täpselt nendele kutsetele, nii et ühendus, mis ei parsi kunagi aadressi, ei saa liidest üldse ehitada.

Seepärast võib loetav logirida nimetada marsruuti, kuigi põhjus on üks samm varasem. Klient jõuab marsruudi etapini alles siis, kui liides on olemas; ilma aadressita ebaõnnestub marsruudikutse kohe või ei käivitu kunagi. Kui log ütleb, et marsruuti ei saa lisada, alustage aadressist, mitte marsruudi süntaksist.

Kontroll 1: kas server paneb vastusesse aadressi?

Marsruuditud OpenVPN teenuse puhul tuleb aadress serveri poolist või kliendipõhisest määramisest ning topoloogia otsustab selle kuju. OpenVPN 2.4 või uuemas serveris näeb alavõrgu topoloogiaga teenus välja selline:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Sellise kujuga saadab server midagi sellist nagu ifconfig 10.8.0.6 255.255.255.0. Vanem topology net30 paigaldus saadab hoopis partneri aadressi, näiteks ifconfig 10.8.0.6 10.8.0.5, nii et kahe mudeli vahel liigutatud profiil võib tunduda õige, kandes samas vale võrgumaski.

Otsige kliendi ühenduslogist saadetud valikute komplekti. Kui selles pole üldse rida ifconfig, ei saatnud server aadressi või lükkas klient valiku tagasi. Serveris, mis kasutab client-config-dir, peab sertifikaadi common name järgi nimetatud fail olemas olema ja määramist kandma:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Kontroll 2: kas klient hoiab talle antud aadressi?

Liiga lai filter on teine tavaline põhjus. pull-filter on olemas OpenVPN 2.4 ja uuemates versioonides ning kui mitu filtrit sobivad sama valikuga, võidab viimane sobiv, nii et lõppu jäetud kõikehõlmav filter eemaldab aadressi ilma veata:

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

Kitsendage filter valikule, millest tegelikult lahti tahate saada, ja jätke aadress rahule:

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

Nõuanne kõik pullid välja lülitada tuleb tavaliselt kelleltki, kes tahab vabaneda ühestainsast marsruudist. route-nopull on kitsam lüliti: see hoiab ifconfigi ja muud saadetud valikud, lükates tagasi saadetud marsruudid ja DHCP-laadsed valikud. Kasutage seda siis, kui see on tõesti soov, ja vastake aadressi küsimusele eraldi.

Kontroll 3: kas aadress on teie kirjutada?

Käsitsi adresseerimine on õigustatud ainult siis, kui operaator annab teile väärtuse. Kui kirjutate selle ise, peab see tulema VPN-i kliendi alavõrgust, olema aktiivsete sessioonide seas unikaalne ja vastama topoloogiale, mida server käitab. Töölaua silla või kaug-LAN-i hosti aadressi kopeerimine ebaõnnestub mõlemal alusel: telefon nõuaks aadressi, mis on juba mujal olemas, ja lüüsil poleks sellele tagasiteed.

Kaug-LAN-i prefiks marsruudis on sihtkoht, mitte kunagi telefoni identiteet. Marsruut 10.60.0.0/24 jaoks ütleb, et see võrk on kättesaadav tunneli kaudu; see ei ütle midagi selle kohta, milline 10.60.0.x aadress telefonil peaks olema, ja telefonil ei tohiks neist ühtegi olla. Staatilised määramised kuuluvad serveri poolele, kus need ei saa dünaamilise pooliga kokku põrgata.

Kaks sessiooni ühe identiteediga toovad esile sama kokkupõrke. Kui sama sertifikaat ühendub kaks korda ja server saadab mõlemale ühe fikseeritud aadressi, dubleerib teine sessioon esimest, ning lahendus on eraldi identiteedid või eraldi määramised, mitte kliendipoolne muudatus.

Kontroll 4: kas midagi muud hoiab tunnelikohta?

Android lubab korraga ühte aktiivset VPN-teenust. Teine VPN-rakendus või alati sisse lülitatud VPN-kirje, mis on jäetud lubatuks profiilile, mis enam ei tööta, võib selle koha hõivata enne, kui teie OpenVPN klient kutsub establish(). Siis ei ilmugi liides, kuigi profiil on korras, seega katkestage teine VPN, lülitage alati sisse valik välja ja ühenduge uuesti enne, kui profiili puutute.

Teenus, mis nõuab Etherneti sildamist, on teine ummiktee. Juureõigusteta Androidi rakendus saab luua IP-tunneli, mitte sillaühendusega Etherneti segmendi, nii et ükski kirjutatud aadress ei pane dev tap serverit tööle; operaator peab pakkuma marsruuditud teenust. Probleemist teatades lisage kliendi nimi ja versioon, saadetud valikute komplekt, topoloogia ja täpne samm, kus aadress oleks pidanud ilmuma.

Kui kõik neli kontrolli läbivad ning aadress on olemas, unikaalne ja õigesti maskeeritud, muutub marsruudi küsimus tavaliseks: milliseid prefikseid server lubab ja kuidas klient peaks neid piirama. Kirjutage tunneliaadress, selle võrgumask ja topoloogia üles enne, kui midagi muud muudate, sest need kolm väärtust on see, mida operaator peab serveri vaatega võrdlema.