Tuneli iliyogawanywa katika Android VpnService: ni nini unaweza kuelekeza kwa kweli

Tuneli iliyogawanywa katika programu ya VpnService huvunjika katika maeneo machache mahususi, na ukarabati ni tofauti kwa kila moja. Mteja huonyesha lengo moja tu linaloshindikana, kwa hiyo kazi ya kwanza ni kubaini ni mpaka upi unaogusa: njia ambazo builder alipokea, proksi usiyoweza kuthibitisha, resolver uliyotangaza tu, au orodha ya programu ambayo jukwaa hutumia kwa kila mtumiaji. Ndiyo sababu ninahifadhi ukaguzi wa hatua nne. Unakwenda kwa mpangilio ulio hapa chini na hutua kwenye kushindikana kwa kwanza.

Thibitisha kile builder alichokabidhi jukwaa

VpnService.Builder ni orodha ya matamko. establish() hurudisha ParcelFileDescriptor kwa kiolesura pepe, na jukwaa hutuma kwenye kielekezi hicho trafiki inayolingana na viambishi awali vya addAddress na addRoute pekee; addDnsServer huwaambia wateja ni resolver gani waulize. Lengo lililo nje ya viambishi awali vyote ulivyoongeza hufika kamwe kwenye programu yako, chochote kiolesura kinachoahidi. Ukweli huu mmoja unaeleza ripoti nyingi za tuneli iliyogawanywa iliyovunjika kabla ya msimbo kubadilishwa.

Rekodi kwenye kumbukumbu orodha za anwani, njia na DNS ambazo builder yako ilikusanya, kisha zilinganishe na malengo yanayoshindikana. /32 inayokosekana kwa mwenyeji wa usimamizi ni ya kawaida zaidi kuliko tuneli iliyovunjika. Ikiwa orodha ni sahihi, endelea; ikiwa si sahihi, ukaguzi uliobaki ni jitihada bure.

excludeRoute ipo tu kuanzia API 33

Kutenga kwa msingi wa lengo ni ombi linaloishia kuwa uzi wa usaidizi mara nyingi zaidi. builder.excludeRoute(IpPrefix) ilikuja katika API 33; kabla ya hapo, mbinu pekee inayotumika ni kuongeza njia kwa kila kitu isipokuwa kiambishi awali kilichotengwa, kumaanisha lazima uhesabu viambishi awali vya kujazia mwenyewe. Miito miwili si taswira za kioo: mmoja hutoa kutoka kwa seti ya njia za kiolesura, mwingine hujenga seti kutoka sifuri, na kifaa cha zamani kitatupa au kupuuza kimya mwito usiojulikana. Tawanya kwa Build.VERSION.SDK_INT na ujaribu njia zote mbili kwenye maunzi halisi.

Unapohesabu vijazia, angalia upatanisho wa viambishi awali. Kutenga /24 ndani ya njia /16 kunahitaji viambishi awali vifuniko vinavyoeleza kweli salio, si /8 moja iliyoharibika. Rekodi orodha ya mwisho na uthibitishe kwamba mwenyeji aliyetengwa bado anatatuliwa kupitia njia iliyo nje ya tuneli.

Vitambulisho vya proksi haviwezi kuonyeshwa

setHttpProxy(ProxyInfo) huelekeza kiolesura kwenye proksi ya HTTP au SOCKS, na URL ya PAC inaweza kuchagua kati yao kwa kila lengo. ProxyInfo au muundo wa PAC hazibebi jina la mtumiaji na nenosiri, kwa hiyo proksi inayohitaji uthibitishaji inabaki nje ya API ya jukwaa. Programu zinazohitaji hilo kwa kawaida huweka staki ya nafasi ya mtumiaji, tun2socks au injini kama hiyo, na hujibu changamoto ya 407 zenyewe.

Uchaguzi huo una matokeo. Staki ya nafasi ya mtumiaji huona tu trafiki unayoelekeza kwake, kwa hiyo lazima iishi ndani ya mpaka huo wa kielekezi, na hurithi sharti lilelile la protect() kwa soketi yake ya juu. Ukiacha protect(), tuneli hukamata usafirishaji wake yenyewe, jambo linaloonekana kama kupeana mikono kunakokwama baada ya pakiti ya kwanza. Jaribu dhidi ya proksi inayodai vitambulisho, kwa sababu proksi iliyo wazi hupita kwenye njia ya jukwaa na haithibitishi chochote.

Orodha za kila programu na DNS pia ni matamko

Builder ina addAllowedApplication na addDisallowedApplication, na hazipatani: kuita zote mbili hutupa hitilafu. Kwa vyovyote orodha hutumika kwa kila mtumiaji wakati wa kuweka kiolesura, kwa hiyo programu ya wasifu wa kazi huongozwa na tuneli ya wasifu wa kazi na si yako. Kile ambacho hakuna API inayotoa ni udhibiti wa uamuzi wa programu nyingine: huwezi kusukuma pakiti kwenye tuneli yako kutoka nje, na huwezi kufunga au kusanidi upya VPN iliyo tayari hai.

DNS inafuata mtindo huo huo. addDnsServer hutangaza anwani ya resolver; haikuruhusu programu yako kujibu maswali. Ikiwa unataka kutatua majina mwenyewe, endesha resolver na uelekeze anwani yake kwenye tuneli. Programu zinazotumia DoT au DoH kwa jina la mwenyeji lisilobadilika zinaweza kupita anwani uliyotangaza, kwa hiyo chukulia utatuzi wa majina kama jitihada bora isipokuwa unakamata pia njia ya swali.

Manifest, always-on na jaribio la hatua nne

Ustahiki hutangazwa katika manifest: BIND_VPN_SERVICE, kichujio cha intent cha android.net.VpnService na huduma ya mbele ikiwa tuneli lazima idumu chinichini. Always-on VPN pia inahitaji onRevoke safi, kwa sababu mfumo huitta mtumiaji anapobadilisha mipangilio au programu nyingine inapochukua udhibiti.

Endesha ukaguzi kwa mpangilio na utue kwenye kushindikana kwa kwanza. Kwanza, toa orodha za anwani, njia na DNS zilizotolewa kwa builder. Pili, thibitisha establish() ilirudisha kielekezi na soketi ya usafirishaji imelindwa. Tatu, omba lengo moja ndani ya kiambishi awali kilichojumuishwa na moja ndani ya kiambishi awali kilichotengwa. Nne, angalia ni resolver gani iliyojibu kweli kwa kuuliza jina la mwenyeji ambalo resolver yako pekee inaweza kutatua.

Kupeana mikono kumekamilika hakuthibiti hata hatua moja inayofuata. Kila ukaguzi hutenga tabaka moja, kwa hiyo kufaulu kwenye hatua ya pili hakuambii chochote kuhusu ya nne.

Rejea ya VpnService.Builder inaorodhesha uso wote wa builder. Kila kitu unachohitaji zaidi ya hapo ni API nyingine, programu nyingine au staki yako mwenyewe ya nafasi ya mtumiaji, na huo ni uamuzi wa muundo, si hitilafu ya tuneli iliyogawanywa.