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

Ստուգեք՝ հեռակառավարումը միացված է

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

Վերևի ընդունիչը մշակում է միայն անվանված UP և DOWN հարցումներ, ուստի այստեղ թունել ստեղծելու կամ դրա կարգավորումը խմբագրելու ուղի չկա։ Նախքան դրա վրա հենվելը հաստատեք, որ բաղադրիչը առկա է տեղադրված կառուցվածքում․ adb shell dumpsys package com.wireguard.android | grep -i receiver թվարկում է հայտարարված ընդունիչները, և հեռակառավարման ընդունիչ չունեցող կառուցվածքը երբեք չի պատասխանի։ Եթե աշխատահոսքին պետք է այլ վերջնակետ կամ այլ գործընկեր, դա այլ թունել է և ծրագրի ներսում առանձին ձեռքով կարգավորում։

Ստուգեք, թե կառավարիչն ինչ թույլտվություն ունի

WireGuard-ը պաշտպանում է ընդունիչը վտանգավոր թույլտվությամբ՝ com.wireguard.android.permission.CONTROL_TUNNELS, որը պետք է ունենա կառավարող ծրագիրը։ Սեփական հեռարձակումը չի կարող ստեղծել թույլտվություն, որը ուղարկողը երբեք չի հայտարարել կամ երբեք չի ստացել։ Սա այն քայլն է, որտեղ ավտոմատացման բաղադրատոմսերը լուռ ենթադրում են հնարավորություն, որը ավտոմատացումը չունի։

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

adb shell pm list permissions -g -d | grep -i control_tunnels
adb shell dumpsys package net.dinglisch.android.taskerm | grep -i control_tunnels

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

Ստուգեք Intent-ի դաշտերը տեղադրված ծրագրի դեմ

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

Action:  com.wireguard.android.action.SET_TUNNEL_UP
Extra:   tunnel:lab-wg
Package: com.wireguard.android
Target:  Broadcast Receiver

Գործողությունը անվանում է UP կամ DOWN և ուրիշ ոչինչ, լրացուցիչը կրում է ճիշտ կարգավորված թունելի անունը, փաթեթը սահմանափակում է առաքումը WireGuard-ով, և նպատակը պետք է լինի ընդունիչը, ոչ թե ակտիվություն։ Ուղղագրական սխալով թունելի անունը նույն լռությունն է առաջացնում, ինչ անջատված ընդունիչը, ուստի անունը կարդացեք ծրագրում, նախքան եզրակացնելը, որ ավտոմատացումը կոտրված է։ DOWN գործողությունը com.wireguard.android.action.SET_TUNNEL_DOWN է՝ նույն լրացուցիչով և փաթեթով։ Փորձարկման ընթացքում ուղարկեք մեկ հարցում միաժամանակ, որովհետև իրար հետ մրցող երկու հեռարձակումներ ստեղծում են վիճակ, որը ոչ ոք չի կարող վերագրել։

Նույն հարցումը փորձարկեք սարքի shell-ից՝ Intent-ը ավտոմատացումից առանձնացնելու համար։ Եթե այդ հրամանը ձախողվում է, մինչդեռ Tasker-ի առաջադրանքը հաջողվում է, տարբերությունը ուղարկողի թույլտվությունն է, ոչ դաշտերի արժեքները։

adb shell am broadcast -a com.wireguard.android.action.SET_TUNNEL_UP -e tunnel lab-wg --receiver-permission com.wireguard.android.permission.CONTROL_TUNNELS

Ստուգեք, թե ինչ չի ծածկում ձգանը

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

Արգելափակման վարքագիծը բնակվում է բոլորովին այլ տեղ։ adb shell settings get global always_on_vpn_app անվանում է մշտապես միացված որպես ամրացված փաթեթը, իսկ adb shell dumpsys connectivity | grep -i vpn ցույց է տալիս VPN ցանցերը, որոնք համակարգը հիմա հետևում է։ Դրանցից ոչ մեկը չի կարող փոխարինվել գործարկման ձգանով։

Նույն տրամաբանությունը գործում է նստաշրջանի մյուս ծայրում։ Թունելն իջեցնելը, որովհետև մեկ պատուհանը կորցրել է ֆոկուսը, կոտրում է ֆոնային աշխատանքը, նույնականացման օգնականները և ցանկացած այլ ծրագիր, որը հենվել է միացման վրա։ Ֆոկուսի փոփոխության փոխարեն սահմանեք միտումնավոր նստաշրջանի ավարտ, և խուսափեք արագ UP և DOWN հաջորդականություններից, երբ ավտոմատացումը փոխում է համատեքստերը։

Ստուգեք արդյունքը, ոչ թե ուղարկումը

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

Կարդացեք նաև ինտերֆեյսի վիճակը ուղղակիորեն․ adb shell ip -brief addr show tun0 տպում է թունելի ինտերֆեյսը և դրա հասցեն, և առանց հասցեի գոյություն ունեցող ինտերֆեյսը բարձրացված է՝ առանց օգտագործելի լինելու։ Այնուհետև ստուգեք հենց մասնավոր ծառայությունը, որովհետև ձեռքսեղմում կամ երթուղի չունեցող բարձրացված թունելը միևնույն է ձախողվում է այն առաջադրանքում, որը կարևոր էր։ Մեկ անվանված միացում իրական թույլտվության սահմաններում կառավարող ավտոմատացմանը պետք չէ դիպչել ինտերֆեյսին, root հրաման գործարկել կամ թուլացնել Android-ի ցանցային պաշտպանությունները։

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