Skipting tunna í Android VpnService: hvað er raunverulega hægt að beina

Skipting tunna í VpnService-forriti brotnar á nokkrum tilteknum stöðum, og viðgerðin er mismunandi fyrir hvern þeirra. Biðlarinn sýnir aðeins eitt áfangastað sem mistekst, svo fyrsta verkið er að komast að því hvaða mörk þú rekst á: leiðirnar sem builder fékk, proxy-ið sem þú getur ekki auðkennt, resolverinn sem þú tilkynntir aðeins, eða forritalistann sem kerfið beitir fyrir hvern notanda. Einmitt þess vegna held ég fjögurra þrepa athugun. Hún gengur í röðinni hér að neðan og stöðvast við fyrstu mistök.

Staðfestu hvað builder gaf kerfinu

VpnService.Builder er listi yfir yfirlýsingar. establish() skilar ParcelFileDescriptor fyrir sýndarviðmót, og kerfið sendir aðeins umferð sem passar við forskeyti addAddress og addRoute í þá lýsingu; addDnsServer segir biðlurum hvaða resolver þeir eigi að spyrja. Áfangastaður utan allra forskeyta sem þú bættir við nær aldrei í forritið þitt, hvað sem viðmótið lofar. Þessi eina staðreynd útskýrir flestar tilkynningar um brotna skiptingu tunna áður en kóði er breyttur.

Skráðu listana yfir vistföng, leiðir og DNS sem builder þinn setti saman, og berðu þá saman við áfangastaðina sem mistakast. Vantar /32 fyrir stjórnunarhýsil er mun algengara en brotinn tunnel. Ef listinn er réttur skaltu halda áfram; ef hann er rangur er restin af gátlistanum sóað átak.

excludeRoute er aðeins til frá API 33

Undanskilning byggð á áfangastað er beiðnin sem oftast verður að stoðþræði. builder.excludeRoute(IpPrefix) kom í API 33; áður var eina studda nálgunin að bæta leiðum fyrir allt nema undanskilda forskeytið, sem þýðir að reikna sjálf viðbótarforskeytin. Köllin tvö eru ekki spegilmyndir: annað dregur frá leiðasafni viðmótsins, hitt byggir safnið frá núlli, og eldra tæki mun kasta eða hunsa hljóðlega kalli sem það þekkir ekki. Greinðu á Build.VERSION.SDK_INT og prófaðu báðar leiðir á raunverulegum vélbúnaði.

Þegar þú reiknar viðbætur skaltu fylgjast með jöfnun forskeyta. Undanskilning /24 innan leiðar /16 krefst hyljandi forskeyta sem lýsa raunverulega restinni, ekki einnar skakkrar /8. Skráðu lokallistann og staðfestu að undanskildi hýsilinn leysist enn um leið utan tunnans.

Ekki er hægt að tjá auðkenni proxy-sins

setHttpProxy(ProxyInfo) beinir viðmótinu að HTTP- eða SOCKS-proxy, og PAC-vefslóð getur valið milli þeirra fyrir hvern áfangastað. Hvorki ProxyInfo né PAC-sniðið bera notandanafn og lykilorð, svo proxy sem krefst auðkenningar stendur utan API kerfisins. Forrit sem þurfa slíkt byggja yfirleitt inn notendarýmisstakk, tun2socks eða svipaða vél og svara 407 áskoruninni sjálf.

Þessi val hefur afleiðingar. Notendarýmisstakkur sér aðeins umferð sem þú beinir til hans, svo hann verður að lifa innan sömu lýsingarmarka, og hann erfir sömu protect()-kröfu fyrir eigin uppstreymis-socket. Slepptu protect() og tunnillinn grípur eigin flutning, sem birtist sem handaband sem stöðvast eftir fyrsta pakkann. Prófaðu gegn proxy sem krefst auðkennis, því opið proxy stenst á leið kerfisins og sannar ekkert.

Forritalistar og DNS eru líka yfirlýsingar

Builder hefur bæði addAllowedApplication og addDisallowedApplication, og þau útiloka hvort annað: að kalla á bæði kastar undantekningu. Hvort sem er er listinn beittur fyrir hvern notanda við uppsetningu viðmótsins, svo forrit í vinnusniði stjórnast af tunni vinnusniðsins en ekki þínum. Það sem ekkert API gefur er stjórn á ákvörðun annars forrits: þú getur ekki ýtt pakka inn í tunnilinn þinn að utan, og þú getur ekki lokað eða stillt VPN sem er þegar virkt.

DNS fylgir sama mynstri. addDnsServer tilkynnir resolver-vistfang; það leyfir forritinu þínu ekki að svara fyrirspurnum. Ef þú vilt leysa nöfn sjálf skaltu keyra resolver og beina vistfangi hans inn í tunnilinn. Forrit sem nota DoT eða DoH á fast hýsilnafn geta farið fram hjá vistfanginu sem þú tilkynntir, svo líttu á nafnaleysingu sem bestu tilraun nema þú grípir einnig fyrirspurnarleiðina.

Manifest, always-on og fjögurra þrepa prófið

Hæfi er tilkynnt í manifestinu: BIND_VPN_SERVICE, intent-síunnar android.net.VpnService og forgrunnsþjónustu ef tunnillinn á að lifa af í bakgrunni. Always-on VPN krefst auk þess hreins onRevoke, því kerfið kallar á hann þegar notandinn breytir stillingum eða annað forrit tekur yfir.

Keyrðu athuganirnar í röð og stöðvaðu við fyrstu mistök. Fyrst skaltu skrá listana yfir vistföng, leiðir og DNS sem builder fékk. Næst skaltu staðfesta að establish() hafi skilað lýsingu og að flutningssokkurinn sé varinn. Þriðja, biddu um einn áfangastað innan innifalins forskeytis og einn innan undanskilins. Fjórða, athugaðu hvaða resolver svaraði í raun með því að spyrja hýsilnafn sem aðeins þinn resolver getur leyst.

Lokið handaband sannar engu af síðari þrepunum. Hver athugun einangrar eitt lag, svo árangur í öðru þrepi segir ekkert um það fjórða.

VpnService.Builder-viðmiðin telja upp allt yfirborð buildersins. Allt sem þú þarft handan þess er annað API, annað forrit eða þinn eigin notendarýmisstakkur, og það er hönnunarákvörðun en ekki villa í skiptingu tunna.