Android հավելվածը հրաժարվում է աշխատել VPN-ով․ ո՞ր շերտն է որոշում

Երբ Android հավելվածը դադարում է աշխատել այն պահին, երբ թունելը բարձրանում է, մեղավոր կարող են լինել երեք տարբեր բաներ, և նրանք տալիս են նմանատեսք խափանումներ։ Հավելվածը կարող է կարդալ հեռախոսի սեփական ցանցի վիճակը և մերժել տեղում։ Սերվերը կարող է դասակարգել այն հասցեն, որտեղից գալիս եք, և մերժել այն։ Կամ մերժումը կարող է ընդհանրապես կապ չունենալ VPN-ի հետ։ Ներքևի հերթականությունը ապացույցներ է հավաքում նախքան ինչ-որ բան փոխելը, որովհետև ելքը փոխելը ամենաթանկ քայլն է և ամենաքիչ հավանականը, որ կօգնի, եթե ստուգումը տեղական է։

Քայլ 1․ պարզել, երբ է հավելվածը մերժում

Ժամանակը առաջին տարբերիչն է։ Մաքրեք մատյանի բուֆերը, վերարտադրեք խափանումը և նայեք, թե ինչ արեց հավելվածը նախքան բողոքելը․

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

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

Այդ ժամանակը վերաբերվեք որպես ապացույց, ոչ որպես հաստատում։ Հավելվածը կարող է վերարտադրել պահված պատասխան, և ֆոնային հարցումները կարող էին հաջողվել կամ ձախողվել նախքան ձեր նայելը։ Գրանցեք վերջին հաջող հարցման և սխալի ժամանակի նշանները, ոչ միայն այն պահը, երբ հայտնվեց հաղորդագրությունը։

Քայլ 2․ կարդալ հեռախոսի սեփական տեսակետը ցանցի վրա

Android-ը բացահայտում է VPN վիճակը որպես ցանցի հնարավորություն, այնպես որ հավելվածին պետք չէ առևտրային մատակարարների ցանկ՝ թունելի ակտիվությունը նկատելու համար։ Այն հարցնում է կապակցվածության ծառայությանը, թե որն է ընթացիկ ցանցը, և պատասխանը ներառում է VPN տրանսպորտի բիթ․

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

Այդ ստուգումը տեղական է և էժան, և բացատրում է «այս հավելվածը չի աշխատում VPN-ով» տիպի ամբողջ դասը՝ առանց որևէ հեռավոր դասակարգման։ Ինչ հավելվածը կարող է տեսնել, դեռ կախված է իր սեփական ցանցային համատեքստից, ուստի մի ենթադրեք, որ ամեն հավելված ստուգում է սարքի ամեն պրոֆիլ։

Աշխատանքային կայանից դուք կարող եք տեսնել նույն վիճակը փորձնական սարքում adb shell dumpsys connectivity-ով և VPN ցանցի գրառումը փնտրելով։ Համեմատեք թունելը բարձրացված վիճակով մեկ աշխատանքը թունելը իջեցված աշխատանքի հետ և պահպանեք երկու արդյունքները։

Քայլ 3․ կարդալ, թե սերվերն իրականում ինչ է տեսնում

Մյուս դիտորդը ծառայությունն է։ Այն տեսնում է եկող աղբյուրի հասցեն և կարող է գործել ըստ հասցեի, դրա հետևում գտնվող հոսթինգ ցանցի, տարածաշրջանի, օպերատորի կամ հաշվին ու սարքին կապված ազդանշանների։ Դրանցից ոչ մեկը եզակի ինքնություն չէ, և ընդհանուր հասցեավորումը կողմնակի արգելափակումները դարձնում է սովորական․ մեկ սահմանափակ հասցե կարող է դուրս հանել նույն թարգմանության հետևում գտնվող անկապ օգտատերերին։

Ստացեք հասցեն այն նույն ուղով, որն օգտագործում է հավելվածը, ոչ թե նոութբուքի զննարկիչից։ Հեռախոսում հասցեի արձագանքման ծառայությանը պարզ հարցումը ցույց է տալիս, թե ինչ է ստանում հեռավոր կողմը, և դա բջջային ցանցով արված հարցման հետ համեմատելը ձեզ ասում է՝ հասցեն ընդհանրապես փոխվել է, թե ոչ։

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

Քայլ 4․ համապատասխանեցրեք ապացույցները երեք վճիռներից մեկին

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

Գրեք վճիռը դրա առաջացրած ապացույցի հետ միասին։ Այս քայլի արժեքը նրանում է, որ այն կանգնեցնում է այն օղակը, որտեղ ինչ-որ մեկը չորս անգամ փոխում է ելքային հանգույցները՝ ուղղելու ստուգում, որը գործարկվում է հենց հեռախոսի վրա։

Այն նաև պահում է պնդումները ազնիվ։ Սեփական հոսթինգը փոխում է վերջնակետը և դրա ինտերնետ ելքը․ այն չի ստիպում Android-ին մոռանալ, որ VPN ցանցը ակտիվ է, և չի երաշխավորում հասցեները դասակարգող ծառայության կողմից ընդունում։ Տեղական զտիչը կարող է գործարկվել ձեր սեփական VPN ցանցում նույնքան հեշտ, որքան առևտրայինում։

Քայլ 5․ գնացեք աջակցվող ուղով և ստուգեք այն

Սկսեք արտադրանքի փաստաթղթավորված քաղաքականությունից և դրա աջակցության պատասխանատուից։ Ուղարկեք հաճախորդի տարբերակը, ճշգրիտ հաղորդագրությունը և խափանման նեղ պատուհանը․ մի ուղարկեք ամբողջական երթևեկության գրառումներ կամ հավատարմագրեր միայն սխալի գոյությունն ապացուցելու համար։

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

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