Ինչպես կարդալ VPN-ի և պրոքսիի վիճակը կառավարվող աշխատանքային հավելվածի համար

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

Սկսեք հավելվածից և նրա պրոֆիլից

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

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

Կարդացեք այն վիճակը, որը հաղորդում է հարթակը

Ձեր աջակցության գործիքների գոյություն ունեցող ակտիվության ներսում, API 23 կամ ավելի նորում, ցանցի վիճակը կարելի է կարդալ առանց մեկ բայթ ուղարկելու։ Կանչին անհրաժեշտ է սովորական ACCESS_NETWORK_STATE մանիֆեստի թույլտվությունը՝ հնարավորությունները կարդալու համար։

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

Յուրաքանչյուր արժեք պատասխանում է նեղ հարցի։ Ակտիվ ցանցը կանչող գործընթացի լռելյայն ցանցն է այդ պահին։ Հնարավորությունների ստուգումը ձեզ ասում է՝ արդյոք այդ լռելյայն ցանցը VPN-ով ապահովված է։ Պրոքսիի կանչը հաղորդում է գործող լռելյայն HTTP պրոքսին, և վերադարձված օբյեկտը կարող է նկարագրել կամ ստատիկ պրոքսի, կամ PAC սկրիպտ։

Եթե ձեզ անհրաժեշտ է ըստ ցանցի տեսքը՝ լռելյայնի փոխարեն, կարդացեք նույն ցանցի կապի հատկությունները և համեմատեք cm.getLinkProperties(network)?.httpProxy-ի հետ։ Սարքի կառավարման կողմից տեղադրված պրոքսին երևում է լռելյայն պրոքսիի կանչում և չի երևում կապի հատկություններում, ինչը արագ միջոց է քաղաքականությամբ տրված պրոքսին ցանցի տվածից տարբերելու համար։

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

Մեկնաբանեք յուրաքանչյուր դաշտ նեղ

Զրոյական ցանցը կամ զրոյական հնարավորությունների օբյեկտը նշանակում է, որ կանչողի ցանցի վիճակը հասանելի չէր կամ փոխվել է ընթերցման ընթացքում։ Դա չի նշանակում, որ VPN չկա։ Վերաբերվեք դրան որպես անհայտ և կրկին կարդացեք այն բանից հետո, երբ հավելվածը եկել է առաջին պլան, ոչ թե որպես բացասական արդյունք։

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

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

PAC-ը այն դեպքն է, որը հաղթում է մեկ արժեքով պատասխանին։ Սկրիպտը կարող է մեկ նպատակակետ ուղարկել պրոքսիով, իսկ մյուսը՝ ուղիղ, ուստի նույն հավելվածի երկու հարցում մեկ վայրկյանի ընթացքում կարող են տարբեր ուղիներ բռնել։ Եվ այն հավելվածը, որը իր սոքեթները կապում է ընտրված ցանցին կամ կանչում է bindProcessToNetwork, ամենևին պարտավոր չէ հետևել լռելյայնին։

Ինչ չի կարող ասել այս լուսանկարը

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

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

Ահա թե ինչու երկու կեսերը միասին նշանակալի են՝ լուսանկարը նեղացնում է, թե որտեղ նայել, իսկ հավելվածի սեփական ախտորոշումը ասում է, թե ինչն է իրականում ձախողվել։

Հաղորդեք այն ձևով, որով ադմինիստրատորը կարող է օգտվել

Տվեք տուժված հավելվածը, պրոֆիլը, ժամանակի դրոշմը և ճշգրիտ փուլը, որը ձախողվել է՝ անվան լուծում, TCP կապ, TLS ձեռքսեղմում կամ HTTP կարգավիճակ։ Ավելացրեք լուսանկարի արժեքները այնպես, ինչպես կարդացվել են՝ զրոները գրված որպես զրո, ոչ թե որպես ոչինչ բառ։ Նշեք՝ արդյոք նույն պրոֆիլի այլ հավելվածներ նույն կերպ են ձախողվում, ինչը հավելվածի խնդիրը տարբերում է ամբողջ պրոֆիլի ուղու խնդրից։

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

Լռելյայն պրոքսիի պայմանագիրը կարճ է և արժե մեկ անգամ կարդալ, քանի որ այն հստակ սահմանում է, թե որ պրոքսին է հաղորդում կանչը, և այս լուսանկարի ամեն չափազանց ընթերցում սկսվում է այն ենթադրությամբ, որ այն ավելին է հաղորդում։