Split tunneling Android VpnService'is: mida saab tegelikult suunata

Split tunneling läheb VpnService'i rakenduses katki mõnes üksikus kohas ja parandus on igas kohas erinev. Klient näitab ainult ühte sihtkohta, mis ebaõnnestub, seega on esimene ülesanne välja selgitada, millise piirini te jõuate: marsruudid, mille builder sai, puhverserver, mida te ei suuda autentida, resolver, mille te ainult teatasite, või rakenduste loend, mida platvorm rakendab iga kasutaja kohta. Just seetõttu hoian nelja sammu kontrolli. See käib allpool toodud järjekorras ja peatub esimese tõrke juures.

Kinnitage, mida builder platvormile andis

VpnService.Builder on deklaratsioonide loend. establish() tagastab virtuaalse liidese jaoks ParcelFileDescriptori ja platvorm saadab sellesse deskriptorisse ainult liikluse, mis vastab addAddress ja addRoute prefiksitele; addDnsServer ütleb klientidele, millist resolverit küsida. Sihtkoht, mis jääb väljapoole kõiki teie lisatud prefikseid, ei jõua kunagi teie rakendusse, ükskõik mida liides lubab. See üks fakt seletab enamikku teateid katkise split tunneling'u kohta juba enne koodimuudatusi.

Logige loendid aadressidest, marsruutidest ja DNS-ist, mille teie builder kokku pani, ja võrrelge neid sihtkohtadega, mis ebaõnnestuvad. Puuduv /32 haldushosti jaoks on palju tavalisem kui katkine tunnel. Kui loend on õige, minge edasi; kui vale, on ülejäänud kontroll-loend raisatud vaev.

excludeRoute on olemas alles API 33-st

Sihtkohapõhine välistamine on päring, millest kõige sagedamini saab tugiteema. builder.excludeRoute(IpPrefix) saabus API 33-s; enne seda on ainus toetatud lähendus lisada marsruudid kõigele peale välistatud prefiksi, mis tähendab, et komplementaarsed prefiksid tuleb ise arvutada. Need kaks kutset ei ole peegelpildid: üks lahutab liidese marsruudikomplektist, teine ehitab komplekti nullist, ja vanem seade viskab tundmatu kutse või ignoreerib seda vaikselt. Hargnege Build.VERSION.SDK_INT järgi ja testige mõlemat teed reaalsel riistvaral.

Komplementide arvutamisel jälgige prefiksite joondust. /24 välistus /16 marsruudi sees vajab katvaid prefikseid, mis tõesti kirjeldavad ülejäänut, mitte üht vigast /8-t. Logige lõplik loend ja kontrollige, et välistatud host laheneb endiselt väljaspool tunnelit asuval teel.

Puhverserveri mandaate ei saa väljendada

setHttpProxy(ProxyInfo) suunab liidese HTTP või SOCKS puhverserverile ja PAC URL võib sihtkoha kaupa nende vahel valida. Ei ProxyInfo ega PAC-vorming kanna kasutajanime ja parooli, seega autentimist nõudev puhverserver jääb platvormi API-st välja. Rakendused, mis seda vajavad, manustavad tavaliselt kasutajaruumi pinu, tun2socksi või sarnase mootori ja vastavad 407 väljakutsele ise.

Sellel valikul on tagajärjed. Kasutajaruumi pinu näeb ainult liiklust, mille te sinna suunate, seega peab see elama sama deskriptori piiri sees ja pärib sama protect() nõude oma ülesvoo pistikprogrammi jaoks. Jätke protect() vahele ja tunnel püüab kinni omaenda transpori, mis avaldub käepigistusena, mis takerdub pärast esimest paketti. Testige puhverserveri vastu, mis nõuab mandaate, sest avatud puhverserver läbib platvormi tee ja ei tõesta midagi.

Rakenduste loendid ja DNS on samuti deklaratsioonid

Builderil on nii addAllowedApplication kui ka addDisallowedApplication ning need välistavad teineteist: mõlema kutsumine viskab erindi. Mõlemal juhul rakendatakse loendit iga kasutaja kohta liidese seadistamisel, seega tööprofiili rakendust juhib tööprofiili tunnel, mitte teie oma. Mida ükski API ei anna, on kontroll teise rakenduse otsuse üle: te ei saa paketti väljastpoolt oma tunnelisse suruda ega juba aktiivset VPN-i sulgeda või ümber seadistada.

DNS järgib sama mustrit. addDnsServer teatab resolveri aadressi; see ei luba teie rakendusel päringutele vastata. Kui tahate nimesid ise lahendada, käivitage resolver ja suunake selle aadress tunnelisse. Rakendused, mis kasutavad DoT-i või DoH-d fikseeritud hostinime vastu, võivad teie teatatud aadressist mööda minna, seega käsitlege nimede lahendamist parima pingutusena, kui te ei püüa kinni ka päringuteed.

Manifest, always-on ja nelja sammu test

Kõlblikkus deklareeritakse manifestis: BIND_VPN_SERVICE, android.net.VpnService intent-filter ja foreground-teenus, kui tunnel peab taustal püsima. Always-on VPN nõuab lisaks puhast onRevoke'i, sest süsteem kutsub seda siis, kui kasutaja muudab seadeid või teine rakendus võtab juhtimise üle.

Tehke kontrollid järjekorras ja peatuge esimese tõrke juures. Esiteks, trükige välja aadresside, marsruutide ja DNS-i loendid, mis builderile anti. Teiseks, kinnitage, et establish() tagastas deskriptori ja et transpordi pistikprogramm on kaitstud. Kolmandaks, küsige üht sihtkohta kaasatud prefiksi sees ja üht välistatud prefiksi sees. Neljandaks, kontrollige, milline resolver tegelikult vastas, küsides hostinime, mida ainult teie resolver suudab lahendada.

Lõpetatud käepigistus ei tõesta ühtki järgnevat sammu. Iga kontroll isoleerib ühe kihi, seega teise sammu õnnestumine ei ütle neljanda kohta midagi.

VpnService.Builderi viide loetleb kogu builderi pinna. Kõik, mida sellest enam vajate, on teine API, teine rakendus või teie oma kasutajaruumi pinu, ja see on disainiotsus, mitte split-tunneling'u viga.