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-аас гадуур үлддэг. Үүнийг шаарддаг аппууд ихэвчлэн хэрэглэгчийн орон зайн стек, tun2socks эсвэл түүнтэй төстэй хөдөлгүүр суулгаж, 407 сорилтод өөрсдөө хариулдаг.

Энэ сонголт үр дагавартай. Хэрэглэгчийн орон зайн стек зөвхөн түүн рүү чиглүүлсэн урсгалыг хардаг тул ижил дескрипторийн хил дотор амьдрах ёстой бөгөөд өөрийн 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, өөр апп эсвэл таны өөрийн хэрэглэгчийн орон зайн стек бөгөөд энэ нь хуваагдсан туннелийн алдаа бус, дизайны шийдвэр юм.