Կարդացեք Android DNS-ը ճիշտ՝ ըստ ցանցի, ոչ թե resolv.conf-ում

Ձեր Android հավելվածը լուծում է ցանցի համար նախատեսված resolver-ով, ոչ թե հենց նոր կարդացած resolv.conf-ով։ Սկզբում ստուգեք LinkProperties-ը, socket-ի կապերը և Private DNS-ը։

Դուք ստանում եք shell սարքում, կարդում եք /etc/resolv.conf-ը կամ հանում եք հին net.dns1 արժեք, և ստանում մեկ հասցե։ Ձեր առջևի հավելվածը լուծում է բոլորովին այլ բանի միջոցով։ Ընթացիկ Android թողարկումում resolver-ը ըստ ցանցի է․ համակարգը պահում է քաղաքականություն յուրաքանչյուր Network-ի համար և կիրառում այն հարցումն ուղարկած socket-ի վրա։ Ֆայլը և հին հատկությունը մնացորդներ են, և դրանցից ոչ մեկը չի նկարագրում այն ուղին, որով ձեր հարցումն իրականում անցել է։

Այդ բացը երևում է split-tunnel-ի և Private DNS-ի ներդրման ժամանակ, երբ նույն հեռախոսի երկու հավելված կարող են օրինականորեն տեսնել տարբեր պատասխաններ։ Այս ուղեցույցը սկսվում է սխալ կամ բացակայող լուծումից և հետ է գնում դեպի այն կոնֆիգուրացիան, որին այն պատկանում է։

Resolver-ը պատկանում է ցանցին, ոչ թե սարքին

Անունների լուծումը Android 9-ում և ավելի նորում անցնում է համակարգային resolver-ով, որը հենվում է այն Network-ի վրա, որին socket-ը կապված է։ Յուրաքանչյուր ցանց ունի իր LinkProperties-ը, և այդ հատկությունները պարունակում են DNS սերվերների ցանկը, որոնման դոմենները և Private DNS-ի վիճակը միայն այդ ցանցի համար։ Այդ մոդելում ոչինչ չի համապատասխանում ֆայլից կարդացվող միասնական սարքային ցանկի։

VPN-ը բաժանումն ակնհայտ է դարձնում։ Երբ թունելը բարձրանում է, VPN հավելվածը տրամադրում է DNS սերվերներ, որոնք գրանցված են VPN-ի սեփական ցանցում, այնպես որ դրա միջով ուղղորդված հավելվածները լուծում են այդ սերվերներում, մինչ բացառված հավելվածները շարունակում են օգտագործել տակի ցանցը։ Մեկ սարք, երկու պատասխանի ուղի, հակասություն չկա։

Կարդացեք պատկերը տուժած հավելվածի ներսից

Հարցրեք հենց հավելվածին։ Մեթոդը, որն ունի Context և սովորական android.permission.ACCESS_NETWORK_STATE թույլտվություն, կարող է կարդալ պատկերը՝ չդիպչելով համակարգային հատկություններին․

val cm = getSystemService(ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val links = network?.let { cm.getLinkProperties(it) }

val dnsServers = links?.dnsServers
val privateDnsActive = links?.isPrivateDnsActive
val privateDnsName = links?.privateDnsServerName

activeNetwork-ը ձեր գործընթացի լռելյայն ցանցն է, ոչ թե սարքի միակ ցանցը, և կարող է null լինել, երբ կանչողը չունի օգտագործելի լռելյայն։ Արգելափակված լռելյայն VPN-ը սովորական պատճառն է։ isPrivateDnsActive-ը ձեզ ասում է՝ այդ ցանցի հարցումները TLS-ով գնում են անվանված resolver, ինչը փոխում է այն, ինչ ցույց կտա պարզ UDP 53 ստուգումը։ API-ի մակերեսը փաստաթղթավորված է LinkProperties-ի տակ, և դրա յուրաքանչյուր արժեք կոնֆիգուրացիայի պատկեր է, ոչ թե ապացույց, որ կոնկրետ հարցումը հասել է կոնկրետ սերվերի։

Երբ լռելյայն ցանցը այն չէ, որն անում է աշխատանքը

Պատկերը պատասխանում է միայն լռելյայի համար։ Հավելվածը կարող է կապել իր գործընթացը կամ մեկ socket այլ ցանցի, և այդ դեպքում լուծումը հետևում է այդ ընտրությանը, մինչ ձեր ախտորոշումը դեռ հաղորդում է լռելյայնը։ Իր սեփական DNS-over-HTTPS resolver-ը բերող դիտարկիչը բոլորովին չի դիմում համակարգային ցանկին, ուստի նրա պատասխանները ոչինչ չեն ասում սարքի մնացածի մասին։ Աշխատանքային պրոֆիլի հավելվածը աշխատում է առանձին օգտվողի ներքո՝ իր քաղաքականությամբ։ Նախքան սերվերներին մեղադրելը ստուգեք կապը։

VPN-ի ինտեգրումը երկրորդ կեսն է։ dhcp-option DNS տողը OpenVPN պրոֆիլում ընդունելը և այդ հասցեն Android VPN ցանցում գրանցելը երկու առանձին քայլ են, և սերվերին հասնող ուղու բացակայությունը ձախողվում է այնքան լուռ, որքան սխալ հասցեն։ Զարգացման մեքենայից adb shell dumpsys connectivity-ն տպում է նույն կապի հատկությունները ըստ ցանցի, երբ build-ը դա թույլ է տալիս, ինչը հաստատում է ցանկը՝ առանց կոդ գրելու։

Համեմատեք կոնֆիգուրացիան մեկ լուծման հետ, որը ձեզ թույլատրված է

Ընտրեք անուն, որը պետք է լուծվի մասնավոր անունների տիրույթում, և մեկ հանրային անուն, և գրեք երկու արդյունքները պատկերի կողքին՝ ցանց, կարգավորված սերվերներ, Private DNS-ի վիճակ և սխալի ստույգ տեքստը։ Անվանված սերվերին ուղղված ուղիղ հարցումը ապացուցում է, որ այդ սերվերը պատասխանում է ձեզ․ այն չի ապացուցում, որ սովորական հավելվածային լուծումը ընտրել է հենց նրան։ Քեշում եղած պատասխանը նոր թեստ չէ, ուստի մաքրեք քեշը կամ օգտագործեք անուն, որն այսօր ոչ ոք չի հարցրել։

Եթե resolver-ը սպասարկում է միայն որոշակի մուտքի ցանցի հաճախորդների, ապա այն, ինչ նա տեսնում է VPN-ից ելքից հետո, կարող է որոշել արդյունքը, և դա քաղաքականության հարց է նրա համար, ով կառավարում է այն, ոչ թե ապացույց, որ օպերատորները արգելափակում են UDP 53-ը։ Այնտեղ, որտեղ Private DNS-ը ակտիվ է, ոչ լիարժեք հոսթի անունը կարող է մերժվել դիզայնով, մինչ նույն սերվերը սովորաբար պատասխանում է հանրային անուններին։ Հատկությունները կարդալը ձեզ ասում է, թե որ ռեժիմն է գործում, ուստի դադարում եք գուշակել փաթեթների զտիչները։

Ուղղեք այն շերտը, որին պատկանում է անհամապատասխանությունը

Աշխատեք վերև, փոխանակ խմբագրեք գլոբալ վիճակը։ Եթե հավելվածը կապված է սխալ ցանցին, ուղղեք կապը։ Եթե պրոֆիլը տալիս է սխալ DNS ընտրանք, ուղղեք պրոֆիլը։ Եթե Private DNS-ը խիստ է ցանցում, որի resolver-ը չի կարող սպասարկել ձեր մասնավոր գոտին, դա սարքի կառավարման որոշում է, ոչ թե ֆունկցիան ամենուր անջատելու պատճառ։

Հանրային resolver-ները DHCP կեռիկի կամ համակարգային հատկության մեջ մղելը այն վերանորոգումն է, որն անընդհատ միջադեպեր է առաջացնում․ մասնավոր անունները դադարում են լուծվել, փոփոխությունը գոյատևում է VPN նստաշրջանից, և սարքում հաջորդ մարդը գտնում է տիրոջից զուրկ հնացած հասցե։ Պահեք փոփոխությունը VPN-ի, հավելվածի կամ կառավարման շերտի ներսում, որին պատկանում է անհամապատասխանությունը, ապա նորից կարդացեք պատկերը՝ հաստատելու, որ սերվերների ցանկն իսկապես փոխվել է։

Վերջում դուք ուզում եք մեկ հավելվածային հարցում՝ կապված մեկ ցանցի, resolver-ների ցանկի և Private DNS-ի վիճակի հետ։ Երբ կարողանաք ցույց տալ այդ շղթան, ֆայլում ծանոթ հասցեն այլևս ոչնչի ապացույց չէ։

Առնչվող հոդվածներ