Android VpnService'те бөлүнгөн туннель: чындыгында эмнени маршруттоого болот

VpnService колдонмосунун бөлүнгөн туннели бир нече так жерден бузулат жана ар биринин оңдоосу башка. Кардар пайдасыз бир гана багытты көрсөтөт, ошондуктан биринчи иш кайсы чекке түртүлүп жатканыңызды аныктоо: builder алган маршруттар, аутентификация кыла албаган прокси, эрк гана жарыялаган resolver же платформа ар бир колдонуучуга колдонгон колдонмо тизмеси. Так ушундан улам төрт баскычтуу текшерүүнү кармайм. Ал төмөнкү тартипте жүрөт жана биринчи ийгиликсиздикте токтойт.

Builder платформага эмнени бергенин ырастаңыз

VpnService.Builder — декларациялардын тизмеси. establish() виртуалдык интерфейс үчүн ParcelFileDescriptor кайтарат, ал эми платформа ошол дескрипторго addAddress жана addRoute префикстерине туура келген трафикти гана жөнөтөт; addDnsServer кардарларга кайсы resolver'ден сурашты айтат. Кошкон бардык префикстериңизден сырттагы багыт интерфейс эмне убада кылса да колдонмого эч качан жетпейт. Ушул бир факт кодду өзгөртүүгө чейинки бузулган бөлүнгөн туннель тууралуу билдирүүлөрдүн көбүн түшүндүрөт.

Builder кураган дарек, маршрут жана DNS тизмелерин журналга жазып, аларды ийгиликсиз болгон багыттар менен салыштырыңыз. Башкаруу хосту үчүн жок /32 бузулган туннелден алда канча көп кездешет. Тизме туура болсо улантыңыз; туура эмес болсо калган текшерүү тизмеси бош эмгек.

excludeRoute API 33төн гана бар

Багытка негизделген чыгаруу эң көп колдоо темасына айланган өтүнүч. builder.excludeRoute(IpPrefix) API 33тө келди; анга чейин колдоого алынган жалгыз жакындоо — чыгарылган префикстен башка бардыгына маршрут кошуу, башкача айтканда толуктоочу префикстерди өзүңүз эсептешиңиз керек. Эки чакыруу күзгүдөгү чагылдыруу эмес: бири интерфейстин маршрут жыйындысынан кемитет, экинчиси жыйынды нөлдөн курат, ал эми эски түзмөк тааныбаган чакырууну ыргытат же үнсүз этибарга албайт. Build.VERSION.SDK_INT боюнча бутактанып, эки жолду тең чыныгы жабдууда сынаңыз.

Толуктоолорду эсептегенде префикстин тегиздигине көңүл буруңуз. /16 маршруттун ичиндеги /24 чыгаруу калган бөлүгүн чындап сүрөттөгөн жабуучу префикстерди талап кылат, бузук бир /8 эмес. Акыркы тизмени журналга жазып, чыгарылган хост дагы эле туннелден тышкаркы жол менен чечилерин ырастаңыз.

Проксинин каттоо маалыматтарын билдирүү мүмкүн эмес

setHttpProxy(ProxyInfo) интерфейсти HTTP же SOCKS проксисине багыттайт, ал эми PAC URL ар бир багыт үчүн экөөнүн ортосунда тандоо кыла алат. ProxyInfo да, PAC форматы да колдонуучу атын жана сырсөздү алып жүрбөйт, ошондуктан аутентификация талап кылган прокси платформанын API сыртында калат. Ага муктаж колдонмолор адатта userspace стекти, tun2socks же ушуга окшош кыймылдаткычты камтыйт жана 407 чакырыгына өздөрү жооп берет.

Бул тандоонун кесепеттери бар. userspace стек өзүнө багыттаган трафикти гана көрөт, ошондуктан ал ошол эле дескриптор чегинде жашоого тийиш жана өзүнүн uplink сокети үчүн ошол эле protect() талабын мураска алат. protect()ти өткөрүп жиберсеңиз, туннель өзүнүн транспортун кармап калат, бул биринчи пакеттен кийин токтоп калган кол кармашуу түрүндө көрүнөт. Каттоо маалыматтарын талап кылган проксиге каршы сынаңыз, анткени ачык прокси платформанын жолу менен өтөт жана эч нерсени далилдебейт.

Колдонмо тизмелери жана DNS да декларация

Builder'де addAllowedApplication да, addDisallowedApplication да бар жана алар бири-бирин жокко чыгарат: экөөнү тең чакырсаңыз, өзгөчө кырдаал пайда болот. Кандай болбосун тизме интерфейсти жөндөөдө ар бир колдонуучуга колдонулат, ошондуктан жумуш профилинин колдонмосун сиздин туннелиңиз эмес, жумуш профилинин туннели башкарат. Эч бир API бербеген нерсе — башка колдонмонун чечимине көзөмөл: пакетти сырттан туннелиңизге түртө албайсыз жана мурунтан активдүү VPN'ди жаба же кайра конфигурациялай албайсыз.

DNS ушул эле үлгүнү карманат. addDnsServer resolver дарегин жарыялайт; ал колдонмого суроолорго жооп берүүгө жол бербейт. Аттарды өзүңүз чечүүнү кааласаңыз, resolver иштетип, анын дарегин туннелге багыттаңыз. Туруктуу хост атына DoT же DoH колдонгон колдонмолор жарыялаган дарегиңизди айланып өтө алат, ошондуктан суроонун жолун да кармабасаңыз, аттарды чечүүнү эң жакшы аракет деп кабыл алыңыз.

Manifest, always-on жана төрт баскычтуу тест

Жарактуулук manifestте жарыяланат: BIND_VPN_SERVICE, android.net.VpnService intent фильтри жана туннель фондо жашашы керек болсо foreground кызматы. Always-on VPN кошумча таза onRevoke талап кылат, анткени система аны колдонуучу жөндөөлөрдү өзгөрткөндө же башка колдонмо көзөмөлдү алганда чакырат.

Текшерүүлөрдү тартиби менен аткарып, биринчи ийгиликсиздикте токтоңуз. Биринчиден, builder'ге берилген дарек, маршрут жана DNS тизмелерин чыгарыңыз. Экинчиден, establish() дескриптор кайтарганын жана транспорт сокети корголгонун ырастаңыз. Үчүнчүдөн, кошулган префиктин ичиндеги бир жана чыгарылган префиктин ичиндеги бир багытты сураңыз. Төртүнчүдөн, сиздин resolver гана чече алган хост атын сурап, кайсы resolver чындап жооп бергенин текшериңиз.

Бүткөн кол кармашуу кийинки баскычтардын бирин да далилдебейт. Ар бир текшерүү бир катмарды бөлүп турат, ошондуктан экинчи баскычтагы ийгилик төртүнчү тууралуу эч нерсе айтпайт.

VpnService.Builder шилтемеси builder'дин бүт үстүн тизмелейт. Андан тышкары керектүүнүн баары — башка API, башка колдонмо же өзүңүздүн userspace стегиңиз, жана бул дизайн чечими, бөлүнгөн туннелдин катасы эмес.