Android OpenVPN legg ikkje til rute utan tunneladresse

Android-OpenVPN-profilen din legg ikkje til ei rute fordi telefonen ikkje har noka adresse på det virtuelle grensesnittet, så det finst ingenting ei rute kan peike på. Ruter svarar berre på kvar pakkane skal gå. Tunneladressa svarar på kven telefonen er inne i tunnelen, og klienten må levere ei før grensesnittet kan eksistere. Gå gjennom dei fire sjekkane nedanfor i rekkjefølgje og stopp ved første feil, fordi å endre ruter før adressa finst løyner det eigentlege problemet.

Les feilen i den rekkjefølgja klienten utfører han

Android sin VpnService.Builder held dei to omgrepa frå kvarandre: addAddress() set ei adresse på grensesnittet appen byggjer, addRoute() legg til eit destinasjonsprefiks, og establish() nektar å opprette grensesnittet før minst éi adresse er lagd til. Ein OpenVPN-klient kartlegg profilen og alternativa serveren dyttar inn på nettopp desse kalla, så ei tilkopling som aldri parsar ei adresse kan ikkje byggje grensesnittet i det heile.

Difor kan logglinja du les nemne ei rute medan årsaka ligg eitt steg tidlegare. Klienten når rutesteget først etter at grensesnittet finst; utan adresse feilar rutekallet med ein gong eller køyrer aldri. Når loggen seier at han ikkje kan leggje til ei rute, start med adressa og ikkje med rutesyntaksen.

Sjekk 1: set serveren ei adresse i svaret?

For ein ruta OpenVPN-teneste kjem adressa frå bassenget til serveren eller frå ei tildeling per klient, og topologien avgjer kva form ho har. På ein OpenVPN 2.4 eller nyare server ser ei teneste med subnett-topologi slik ut:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Med den forma dyttar serveren noko som ifconfig 10.8.0.6 255.255.255.0. Ein eldre topology net30-installasjon dyttar i staden ei peer-adresse, til dømes ifconfig 10.8.0.6 10.8.0.5, så ein profil som blir flytta mellom dei to modellane kan sjå riktig ut medan han ber feil nettmaske.

Søk i tilkoplingsloggen til klienten etter settet med dytta alternativ. Viss det ikkje inneheld ei einaste ifconfig-linje, har serveren aldri sendt ei adresse, eller klienten har avvist alternativet. På ein server som brukar client-config-dir, må fila som er kalla opp etter common name på sertifikatet finnast og innehalde tildelinga:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Sjekk 2: held klienten på adressa han fekk?

Eit for breitt filter er den nest vanlegaste årsaka. pull-filter finst i OpenVPN 2.4 og nyare, og når fleire filter passar på same alternativ, vinn det siste som passar, så ein catch-all på slutten fjernar adressa utan feil:

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

Avgrens filteret til alternativet du faktisk vil bli kvitt, og lat adressa vere i fred:

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

Rådet om å slå av alle pull kjem vanlegvis frå nokon som vil bli kvitt éi einskild rute. route-nopull er den smalare brytaren: han held ifconfig og dei andre dytta alternativa medan han avviser dytta ruter og DHCP-liknande alternativ. Bruk han når det verkeleg er det du vil, og svar på adresse-spørsmålet separat.

Sjekk 3: er adressa di å skrive?

Manuell adressering er berre legitim når operatøren gir deg verdien. Skriv du éi sjølv, må ho kome frå subnettet til VPN-klienten, vere unik blant aktive økter og passe til topologien serveren køyrer. Å kopiere adressa til ei skrivebordsbru eller ein vert på det eksterne LAN-et feilar på begge punkt: telefonen ville krevje ei adresse som alt finst andre stader, og gatewayen ville ikkje ha nokon returveg til ho.

Det eksterne LAN-prefikset i ei rute er ein destinasjon, aldri identiteten til telefonen. Ei rute for 10.60.0.0/24 seier at nettverket nåast gjennom tunnelen; ho seier ingenting om kva 10.60.0.x-adresse telefonen skal ha, og telefonen skal ikkje ha noka av dei. Statiske tildelingar høyrer heime på serversida, der dei ikkje kan kollidere med det dynamiske bassenget.

To økter på éin identitet avdekkjer den same kollisjonen. Viss det same sertifikatet koplar til to gonger og serveren dyttar éi fast adresse til begge, dupliserer den andre økta den første, og løysinga er separate identitetar eller separate tildelingar i staden for ei endring på klientsida.

Sjekk 4: held noko anna tunnelplassen?

Android tillèt berre éi aktiv VPN-teneste om gongen. Ein annan VPN-app, eller ei alltid-på VPN-oppføring som er latt på for ein profil som ikkje lenger verkar, kan ta den plassen før OpenVPN-klienten din kallar establish(). Då visest aldri grensesnittet sjølv om profilen er gyldig, så kople frå den andre VPN-en, slå av alltid-på-innstillinga og kople til på nytt før du rører profilen.

Ei teneste som insisterer på Ethernet-bruing er den andre blindgata. Ein Android-app utan root kan lage ein IP-tunnel, ikkje eit brua Ethernet-segment, så inga adresse du skriv får ein dev tap-server til å verke; operatøren må tilby ei ruta teneste. Når du rapporterer problemet, ta med klientnamn og versjon, settet med dytta alternativ, topologien og det nøyaktige steget der adressa skulle ha dukka opp.

Viss alle fire sjekkane held og adressa er til stades, unik og riktig maskert, blir rutespørsmålet det vanlege: kva prefiks serveren autoriserer, og korleis klienten bør avgrense dei. Skriv ned tunneladressa, nettverksmaska og topologien før du endrar noko anna, fordi det er desse tre verdiane operatøren treng å samanlikne med visinga til serveren.