Android апп VPN-ээс гадна нэрийг шийдвэрлэдэг: холболтын шалгах хуудас

VPN идэвхтэй байхад ч Android анхдагч сүлжээгээр нэрийг шийдвэрлэж болно. Процессыг VPN сүлжээнд холбож, апп ямар resolver ашигласныг шалгаарай.

VPN клиентийн өөрийн хөтөч рүү нэвтэрч байхад Android апп дотоод нэрийг шийдвэрлэж чадахгүй, мөн ижил бүтээц өөр утсан дээр ажилладаг. URL нь хувьсагч биш. Хувьсагч нь аппын процесст шийдвэрлэхэд аль сүлжээг ашиглахыг зөвшөөрсөн явдал бөгөөд Android таны сокетуудын ашиглаж буй сүлжээ нь идэвхтэй VPN мөн гэдгийг баталгаажуулдаггүй. Эдгээр шалгалтыг дарааллаар нь хийж, resolver-ийн зураг таамаглалтай тань тохирохгүй үед зогсоорой.

1-р алхам: апп аль сүлжээнд байгааг нотлох

Төлөвийн мөр биш, аппын өөрийн харагдацыг уншина. ConnectivityManager-аас идэвхтэй сүлжээ, түүний LinkProperties, DNS серверүүдийн жагсаалт болон хувийн DNS тохиргоог авна. Жагсаалтад VPN-ийн resolver байвал апп түүн рүү замтай; хэрэв Wi-Fi-ийн resolver байвал туннель тухайн процессийн анхдагч сүлжээ биш.

VPN дүрс зөвхөн туннель байгааг хэлнэ. Аппын процесс түүнд холбогдсон гэдгийг хэлэхгүй, Android нэрийн шийдвэрлэлтийг идэвхтэй харагдах сүлжээгээр үргэлж чиглүүлдэггүй. Өөр төхөөрөмж рүү дамжуулдаг локал VPN аппууд, интернетгүй Wi-Fi сүлжээ, үйлдвэрлэгчийн бүтээцүүд аппыг туннелийн серверүүдийн оронд анхдагч resolver-ээс асуухад үлдээж болно.

2-р алхам: VPN тээврийг хүсэж, процессыг холбох

Апп туннелийн resolver-ийг заавал ашиглах бол VPN тээвэртэй сүлжээг хүсэж, callback дотор процессыг холбоно, ингэснээр код сүлжээ хэзээ гарч ирэхийг таамаглахгүй:

val request = NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .build()

connectivityManager.requestNetwork(request, object : NetworkCallback() {
    override fun onAvailable(network: Network) {
        val bound = connectivityManager.bindProcessToNetwork(network)
        Log.i(TAG, "bound to VPN network: " + bound)
    }
})

Энэ дуудлага бүх процессийн анхдагч сүлжээг өөрчилдөг тул дараа нь үүсгэсэн сокет бүр үүнийг ашиглана. Өмнө нь байсан сокетууд үүссэн сүлжээгээ хадгалдаг тул холболтын өмнө нээсэн холболтын пул хуучин замаар шийдвэрлэсээр байж болно. Буцаах утга нь boolean бөгөөд false үр дүн нь холболт болоогүй гэсэн үг; богино сааталтай дахин оролдож, хоёр оролдлогыг тэмдэглэнэ.

3-р алхам: холболтыг хэрэгтэй хэмжээгээр хязгаарлах

Бүх процессыг холбох нь бүдүүлэг. Телеметр, шинэчлэлтийн шалгалт, гуравдагч талын SDK-ууд ч туннель рүү шилждэг, туннель интернетгүй бол тэдгээр бүтэлгүйтэж эхэлдэг. Нэг хүсэлтэд сүлжээний сокет фабрикийг ашиглаж, бусад бүхнийг төхөөрөмжийн анхдагчаар үлдээнэ. Нэг загварыг санаатай сонго: холболт бүрд нарийн холболт, эсвэл VPN алга болоход тодорхой салгах процессын холболт.

Resolver-ийн хоёр онцлог холболтыг ямар ч алдаагүйгээр эвдэж болно. Хатуу горим дахь хувийн DNS хүсэлтүүдийг сүлжээний resolver-ийн оронд нэртэй DoT сервер рүү илгээдэг, өөрийн DNS-over-HTTPS клиенттэй апп системийн resolver-ийг бүрэн тойрдог. Холболт бүтэлгүйтсэн гэж дүгнэхээс өмнө хоёуланг нь шалга. VPN-ийн DNS серверт хэзээ ч хүрэхгүй хүсэлт туннелийн талын ямар ч бүртгэлд харагдахгүй.

4-р алхам: CONNECTED хязгаарлалтад битгий итгэ

WorkManager дахь NetworkType.CONNECTED нь сүлжээ холбогдсон гэсэн үг бөгөөд доорх Wi-Fi эсвэл үүрэн холболт алга болсон ч VPN тээвэр үүнийг хангадаг. Ажил ажиллаж, хүсэлт бүр бүтэлгүйтэж, дахин оролдох бодлого үүнийг хуваарьлалтын алдаа мэт харагдах шуурга болгоно. Туннель бол сүлжээ; хязгаарлалт хэзээ ч интернетийн шалгалт байгаагүй.

Ажилд үнэхээр хэрэгтэй чадварыг шалга, жишээ нь баталгаажсан интернетийн хандалт, мөн буцах алхамтай хязгаарлагдмал дахин оролдлогын бодлогыг баримтал. Ажилд хувийн нэр хэрэгтэй бол ажлыг гүйцэтгэхийн өмнө тэр нэрийг сонгосон сүлжээнд шийдвэрлэж, амжилттай болж чадахгүй хүсэлтийг давтахын оронд тодорхой алдаатай хурдан зогсоо.

5-р алхам: нотолгоог бүртгэж, хүрээг дахин шалга

Сонгосон сүлжээний тээврийн төрлүүд, LinkProperties-ийн DNS серверүүд, холболт true буцаасан эсэх, эхний хүсэлтийн яг бүтэлгүйтлийг бүртгэ. Дараа нь ижил холболтын дор хувийн нэр болон нийтийн нэрийг ажиллуул. Энэ хос апп туннелийн resolver-ийг ашигласан эсвэл чимээгүйгээр төхөөрөмжийн анхдагч руу буцсаныг харуулж, энэ нь хэрэглэгчийн мэдрэх ялгаа юм.

Дэмждэг хамгийн хуучин Android хувилбар болон нэг одоогийн хувилбар дээр давтана. Анхдагч замыг зөв харагдуулдаг resolver-ийн зан төлөв нь төхөөрөмж, хувилбарууд ялгаатай газар мөн, зөвхөн хамгийн шинэ туршилтын төхөөрөмж дээр давдаг бүтээц таны хүргэх хүрээнд баталгаажаагүй. adb shell dumpsys connectivity нь алдааг дахин үүсгэж байхдаа төхөөрөмж ямар сүлжээ, чадвар мэдээлдэгийг хурдан батлах арга.

Холбоотой нийтлэлүүд