VpnService protect() թե՞ հավելվածի բացառում. ինչն է ուղղում երթուղավորումը

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

Ինչ է protect()-ը հեռացնում թունելից

VpnService.protect()-ը յուրաքանչյուր սոքեթի համար կանչ է։ Դուք նրան տալիս եք թունելը կրող սոքեթը կամ դեսկրիպտորը, և Android-ը նշում է այդ սոքեթը, որպեսզի դրա երթևեկությունն օգտագործի հիմքում ընկած ցանցը՝ VPN ինտերֆեյսի փոխարեն։ Մնացած ամեն ինչ, ինչ հավելվածն ուղարկում է, շարունակում է հետևել VPN-ի սովորական երթուղուն։

Հենց այդ նեղ ծավալն է նպատակը։ Պաշտպանված սոքեթը չի փոխում, թե ինչպես է ձեր HTTP հաճախորդը լուծում անունները, թե որ ինտերֆեյսն են օգտագործում ձեր վերլուծական կանչերը, կամ թե ինչ է պատահում ավելի ուշ բացված երկրորդ կապակցությանը։

Երեք պայման, որոնք որոշում են ծավալը

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

Հավելվածը բացառել addDisallowedApplication()-ով կոպիտ գործիք է։ Այն VPN-ից հեռացնում է հավելվածի բոլոր կապակցությունները, ներառյալ նրանք, որոնք ուզում էիք ստուգել, և որոշ սարքերում փոխում է նաև տեղային հայտնաբերման վարքը։

Երրորդ տարբերակը տրանսպորտը ընտրված ցանցին կապելն է bindProcessToNetwork()-ով կամ սոքեթի մակարդակի ցանցային բռնակով։ Սա օգտակար է, երբ սարքը միաժամանակ ունի Wi-Fi և բջջային ցանց, և դուք ուզում եք, որ թունելն անցնի որոշակի վերին ուղով։

Կանչեք այն, երբ տրանսպորտը ստեղծվում է

Կանչեք protect()-ը նույն բլոկում, որը ստեղծում է տրանսպորտը, մինչև connect() կամ send()-ը։ Եթե կանչը վերադարձնում է false, փակեք սոքեթը և ձախողեք կարգավորումը. շարունակելը ձեզ թողնում է տրանսպորտ, որի փաթեթները կարող են կրկին մտնել ձեր սեփական ինտերֆեյս։

Ձևն այնքան փոքր է, որ կարելի է պահել մեկ տեղում.

DatagramSocket transport = new DatagramSocket();
if (!protect(transport)) {
    transport.close();
    throw new IOException("transport not protected");
}
transport.connect(serverAddress);

Այստեղ երեք մանրամասնություն է կծում։ Առաջինը,boolean-ը միակ ազդանշանն է, որ ստանում եք, այնպես որ գրանցեք ձախողումը բավական համատեքստով, որպեսզի տարբերեք հետ կանչված համաձայնությունը մերժված կանչից։ Երկրորդը,protect()-ը ծածկում է սոքեթը, ոչ դեսկրիպտորի համարը. եթե փակեք սոքեթը և ավելի ուշ նույն ամբողջ թիվը կրկին օգտագործեք այլ սոքեթի համար, նոր սոքեթը պաշտպանված չէ։ Երրորդը, երբ սկզբնական գրադարանը բացում է տրանսպորտը, պաշտպանեք դեսկրիպտորը մինչև սկզբնական կոդի միանալը, այլապես երթուղին կարող է արդեն ընտրված լինել։VpnService-ի տեղեկատուն այն տեղն է, որտեղ հաստատում եք, թե ձեր նպատակային API մակարդակը իրականում ինչ ծանրաբեռնված տարբերակներ է տալիս։

Փորձարկեք արգելափակված ուղին, ոչ միայն երջանիկ ուղին

Ստուգեք թունելը միացված վիճակում, որովհետև դա միակ վիճակն է, երբ երկու ուղիները կարող են տարբերվել։ Ուղարկեք մեկ հարցում պաշտպանված տրանսպորտով, և մեկը՝ կոդի ուղուց, որը երբեք չի կանչել protect()-ը, ապա համեմատեք, թե ինչ է տեսնում հեռավոր ծայրը. պաշտպանված կապակցությունը պետք է հասնի հիմքում ընկած ցանցով որպես աղբյուր, մինչդեռ չպաշտպանվածը ցույց է տալիս թունելի սեփական հասցեն և շարժում է թունելի բայթային հաշվիչները։ Սարքում ss կամ netstat-ը ցույց են տալիս նույն բաժանումը մինչև ինչ-որ բան ռադիոյից դուրս գալը։

Փորձարկեք հետկանչը առանձին, որովհետև համաձայնության փոփոխությունը քանդում է ինտերֆեյսը՝ չդիպչելով ձեր սոքեթի կոդին։ Հետ կանչեք VPN համաձայնությունը կամ դադարեցրեք ծառայությունը, վերակառուցեք տրանսպորտը և հաստատեք, որ protect()-ը դեռ վերադարձնում է true, և տրանսպորտը նորից միանում է, հենց որ համաձայնությունը կրկին տրվում է։

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

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