Բացառված հավելվածը դեռ օնլայն է? Հավելվածի և երթուղու կանոնները տարբեր են
Android հավելվածը VPN-ից բացառելը այն չի արգելափակում։ Թույլատրելի ցանկերը, UID կանոնները և ուղարկված երթուղիները որոշում են ուղու տարբեր մասերը։
Փաթեթը բացառելը երթուղավորման հրահանգ է, ոչ արգելափակում, ուստի VPN-ի միացումից հետո բեռնվող էջերը սպասելի են, ոչ թե ձախողման ապացույց։ Բացառումը հավելվածը հանում է թունելից՝ այն արգելափակելու փոխարեն, և սովորական ցանցը կրում է նրա տրաֆիկը։ Այստեղ հանդիպում են երկու առանձին քաղաքականություններ՝ մեկը ընտրում է գործընթացներ, մյուսը՝ նպատակակետեր։ Այդ հերթականությամբ կարդալը բացատրում է, թե ինչու միացված պատկերակը և աշխատող հավելվածը հակասություն չեն։
Ինչու բացառումը ցանցը բաց է պահում
VpnService.Builder-ը ընդունում է կա՛մ թույլատրելի ցանկ, կա՛մ արգելված ցանկ, երբեք երկուսը միասին։ Միայն թույլատրելի ցանկի փաթեթներն են անցնում թունելով։ Արգելված ցանկը շրջում է դա՝ ցանկում նշվածներից բացի յուրաքանչյուր փաթեթ օգտագործում է թունելը, իսկ նշվածները պահում են ֆիզիկական ուղին։ Թույլատրելի ցանկում չնշված փաթեթը նույնպես թունելից դուրս է, ուստի այդ ռեժիմում բացառումը սովորական վիճակ է հավելվածների մեծ մասի համար։
Դա տեղական արգելքի գրառումը դարձնում է երթուղավորման որոշում, ոչ թե firewall-ի կանոն։ Եթե պահանջը հավելվածին հոսթ հասնելը կանխելն է, թունելը պետք է ծածկի այն, և սերվերը կամ տեղական քաղաքականությունը պետք է մերժի տրաֆիկը։ Հավելվածը թունելից հանելը փոխում է միայն այն, թե որ ինտերֆեյսն է կրում նրա փաթեթները։
Play Store-ի դեպքը սովորական դիտավորյալ օրինակն է։ Խանութի փաթեթը բացառելը թույլ է տալիս ներբեռնումներին օգտվել հիմքում ընկած կապից, երբ VPN-ի ելքը խանգարում է փոխանցումներին, և ցույց է տալիս, որ բացառումը նշանակում է շրջանցում, ոչ արգելափակում։
Մեկ պրոֆիլ, մեկ ցանկ
Կառուցիչը բացառություն է նետում, եթե օգտագործվում են երկու կանչերը, ուստի ձեր առջևի պրոֆիլը կա՛մ թույլատրելի, կա՛մ արգելված ցանկ է։ Այդ մեկ փաստը որոշում է, թե ինչպես կարդալ յուրաքանչյուր հետագա դիտարկում։ Ստուգեք կոդը կամ կառավարվող կարգավորումը երթուղային աղյուսակից առաջ, որովհետև ցանկն է որոշում, թե ինչ է նշանակում ելքի մնացած մասը։ Հիբրիդային պրոֆիլը վիճակ չէ, որին կարող եք նայել։
Տարբերությունը նաև կանխատեսում է, թե ինչ կանի նոր տեղադրված հավելվածը։ Թույլատրելի ցանկում այն դուրս է մնում, քանի դեռ ինչ-որ մեկը չի ավելացրել այն, իսկ արգելված ցանկում լռելյայն միանում է թունելին։
Կառավարվող կարգավորումները նույն ընտրությունը ցույց են տալիս տարբեր բանալու անունների տակ, և որոշ կոնսոլներ այն նկարագրում են որպես յուրաքանչյուր հավելվածի VPN ռեժիմ, ոչ թե ցանկ։ Վարքը դեռևս հանգում է այդ երկու կանչերին, ուստի հետևեք կարգավորմանը հետ՝ մինչև փաթեթների ցանկը, փոխարենը պիտակին վստահելու։ Եթե պիտակը և ցանկը չեն համընկնում, հաղթում է ցանկը։
Հետևեք UID կանոնին մինչև թունելի աղյուսակը
Android-ը յուրաքանչյուր հավելվածի տալիս է իր Linux օգտատիրոջ ID-ն, իսկ VPN ծառայությունը տեղադրում է քաղաքականության կանոններ, որոնք համապատասխանում են UID միջակայքերին։ Համապատասխան տրաֆիկը ուղարկվում է երթուղային աղյուսակ, որի լռելյայն երթուղին ուղղված է tun սարքին։ Աղյուսակի համարը տրամադրվում է յուրաքանչյուր VPN օրինակի համար, ուստի այն փոխվում է վերամիացումից կամ երկրորդ VPN պրոֆիլ ստեղծելուց հետո։
Կանոնների ելքը քարտեզն է։ Յուրաքանչյուր տող անվանում է որոնման աղյուսակ, և այդ աղյուսակը պահում է լռելյայն երթուղին, որը որոշում է՝ համապատասխան փաթեթները մտնում են թունել, թե ոչ։
adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>Նախ գործարկեք երրորդ հրամանը՝ UID-ն ստանալու համար, ապա գտեք այն կանոնը, որի միջակայքը պարունակում է այն։ Այդ կանոնը մատնանշում է աղյուսակի համար, և ip route show table <n> այդ համարով ցույց է տալիս՝ արդյոք կա լռելյայն երթուղի tun սարքի միջով։ Եթե աղյուսակը լռելյայն չունի, հավելվածն ընտրված է, բայց ուղի չունի, ինչը այլ ձախողում է։
Այս հրամանները պահանջում են վրիպազերծվող build կամ սարք, որտեղ adb shell-ը կարող է կարդալ ցանցի վիճակը։ Արտադրական հեռախոսում փաթեթների կառավարիչը դեռ պատասխանում է, բայց երթուղավորման ստուգումը կարող է մերժվել, ուստի գրանցեք՝ ինչ կարող եք, և մնացածը համարեք չհաստատված։
Երթուղին պահանջում է նախածանց, ոչ հավելված
Builder.addRoute-ը պահանջում է նպատակակետի նախածանցեր թունելի համար։ Պրոֆիլը, որն ավելացնում է միայն 10.0.0.0/8 ուղարկում է այդ նախածանցը թունելով և թողնում է յուրաքանչյուր այլ նպատակակետ ֆիզիկական ուղու վրա։ Դա սովորական բաժանված թունելավորում է, և կախված չէ նրանից, թե որ հավելվածներն են ընտրել կանոնները։
Սերվերի կողմից ուղարկված կարգավորումը արտացոլում է նույն մոդելը։ Առանձին երթուղու ուղարկումները ավելացնում են նախածանցեր, մինչդեռ redirect-gateway հրահանգը փոխարինում է լռելյայն երթուղին և որսում ամեն ինչ թունելի ծածկած հավելվածների համար։ Այդ հրահանգը հեռացնելը կարող է աշխատող թունելը սեղմել մինչև մեկ ենթացանց՝ առանց սարքում որևէ փոփոխության։
Անսովոր gateway կամ մետրիկ որակիչ ունեցող ուղարկված երթուղին նույնպես կարող է չտեղադրվել։ Նախընտրեք նախածանցի պարզ ձևը և փոխանցումն ու NAT-ը թողեք սերվերին։
Կարդացեք հատումը, նախքան կարգավորումը փոխելը
Թունելը կրում է ծածկված գործընթացների և պահանջված նպատակակետերի հատումը։ Ծածկված հավելվածը, որը հարցնում է հրապարակված նախածանցներից դուրս հասցե, դուրս է գալիս ֆիզիկական ցանցով։ Արգելված փաթեթը դուրս է մնում նույնիսկ այն ժամանակ, երբ հարցնում է այդ նախածանցների ներսում գտնվող հասցե։ Ոչ մի դեպք սխալ չէ. երկուսն էլ այն երկու քաղաքականություններն են, որ անում են իրենց գործը։
Յուրաքանչյուր հավելվածի VPN-ը կարող է նաև կապակցված հավելվածը թողնել առանց կապի։ Երբ on-demand-ը անջատված է, իսկ թունելը՝ վար, հավելվածը մնում է կապված յուրաքանչյուր հավելվածի VPN-ին և պահուստային ուղի չունի, ինչը նման է կոտրված հավելվածի, ոչ թե քաղաքականության վիճակի։ on-demand-ը միացնելը կամ կապակցումը կառավարման միջոցով հեռացնելը փոխում է դա։
| Layer | What it selects | Where to look | Typical mismatch |
|---|---|---|---|
| Package list | Processes | Builder calls or managed configuration | App excluded but expected to be blocked |
| UID policy rule | Which table a UID uses | ip rule show | Tunnel icon on, app still on Wi-Fi |
| Routing table | Destinations for matched traffic | ip route show table <n> | Covered app reaches only one subnet |
| Server push | Prefixes offered to the client | Server route configuration | Tunnel shrinks after a server edit |
Ախտորոշեք մեկ առանցք միաժամանակ։ Նախ հաստատեք թույլատրումը կամ արգելքը, երկրորդ՝ կարդացեք տեղադրված UID կանոններն ու աղյուսակները, և վերջում փորձարկեք երկրորդ հավելվածը նույն նպատակակետի դեմ։ Երկրորդ հավելվածը մեկ հարցման մեջ առանձնացնում է գործընթացի ընտրությունը նպատակակետի ընտրությունից։
Գրառեք արդյունքը որպես հավելված, նպատակակետ և աղյուսակի համար։ Հենց այդ եռյակը պետք է պահպանի հաջորդ փոփոխությունը։